Nice!
Well, it has meaning if you consider the benchmark to be “balls per second”. 128 balls @ 780 fps = 99840 balls/sec, and 3844 balls @ 30 fps = 115320 balls/sec.
maybe the benchmark is meaningless in context of JavaFX or Flash (thats why i opened another thread) but
it always depends what you intending to measure and where you are expecting the bottlenecks. Rendering x moving but independent polygons as fast as possible is a good benchmark to mesure JNI overhead and it might demonstrate best practices which try to reduce JNI calls to a minimum.
There are always people arguing things like: i can render 100 textured cubes in C with 9999FPS but only get 200FPS in java… why should i use java when even this simple scene causes so much overhead for java…etc
the point is java has no chance in GL immediate mode benchmarks but it has if we are able to move the bottleneck to the GPU.
indexed VBOs? are geometry shaders or the latest and greatest gl extensions worth the effort? I don’t know.
this is another valid benchmark benchmarking a completely different area. I agree it is better suited to benchmark highlevel apis like JavaFX or flash since it puts load on the scenegraph.
[edit] btw this wasn’t intended as attack against JavaFX it was rather fun discussion between Spasi and me how to render this stuff fast as possible.
That’s the thing. With the original benchmark you’re not even supposed to be getting 780fps at all, because it is supposed to be throttled to 5ms updates. So you max fps with this benchmark is supposed to be 200fps. After which you’re supposed to look at the cpu consumption to declare the winner.
So the question he original author was asking was
“with 16 balls running at 200fps what kind of cpu usage you could get”
And ideally every implementation should be able to handle even 128 balls (at least images) at 200fps, so your metric (balls per second) would be a constant, since the fps is capped.
Dmitri
Actually I think it’s a better all around approach since it allows you to compare both ends - the low-level apis like Java2D or OpenGL and high level ones like JavaFX and Flash on the same terms.
After a while it doesn’t really matter how many fps you can get from rendering a single rectangle.
It’s like measuring Digger on modern hardware - remember that one? (its animation wasn’t based on time, so when the cpu became faster the Digger became faster too)…
But knowing how many objects your system can handle w/o falling on its butt is I think more important.
As a matter of fact we used to measure system performance in Diggers - how many Digger instances you’d need to start simultaneously before they system slows down enough so that Diggers become playable =) I think around when Pentiums arrived even this measurement became useless =)
I didn’t think it was an attack on anything, I just think you guys are wasting your time implementing this benchmark.
Dmitri
They like wasting their time doing benchmarks 
Cas 
Crazy, crazy people!
yes i am probably crazy since i think there is a paragraph in the JavaFX 1.0 license which prohibits the publication of benchmarks. At least we moved the whole topic away from the scalability issues of the JavaFX 1.0 scenegraph to the topic if benchmarks are cool or not.
Regarding waste of time.
well first define waste of time… games are a waste of time too. I (like the many others too) earn my money in the enterprise that means actually everything i do with 3d graphics in my hobby projects or in those i open sourced is waste of time. :
i had never thought that a handful of numbers would cause this kind of esoteric discussion, actually if i think about it THIS is waste of time too thats why this is my last post on this topic.
I’ve wasted the last 35 years and enjoyed wasting every minute of it 
Cas
60fps for 128 bouncing vector ball should be doable in this modern world. comparing flash for being just as weak shouldn’t be a standing point imo.
Detect it’s the same ball, cache, then draw as image?
[quote=“bienator,post:67,topic:32681”]
I’ll go for it anyway, maybe we’ll learn something useful out of it. Drawing lots of “transformed/scaled alpha-composited balls” is basically particle rendering and 3844 particles at 30fps sounds low for any modern PC.
My point was that it’s not Java2D that’s the cause of poor performance of this JavaFX benchmark.
Dmitri
Of course. AA Share rendering is where Java2D is pretty bad - no question about it.
Dmitri
I’m not arguing about that. I didn’t expect the first JavaFX implementation to have top of the line performance. I’m sure there’s room for lots of optimizations and bug fixes, I trust your team will make it fly soon. It’s the features I miss that I’m worried about.
I’ll try to explain better what I have in mind. Right now I miss 3 important features that I want to add to the projects I’m doing and will do in the future:
- Vector graphics rendering
- Video playback
- A decent sound engine
My only option right now is using middleware crap, which means native per-platform libs, JNI stuff, etc. Or I could waste months to develop something on my own, but I don’t have the time or the know how to do it.
Until JavaFX popped up. It solves 2 out of the 3 problems instantly. Top features, top quality, all pure Java. It even has a scripting language, animations, events, etc, stuff I’d have to roll on my own in a 3D engine. Flash in Java, what more can you ask for? But I can’t use it. Why is it possible to give you any swing component or any BufferedImage and you can draw anything on it, but I can’t give you a simple OpenGL buffer? The code is there, the pipeline is there, just open it up.
Sun already made a great effort by investing on OpenGL with JOGL. The only thing that’s missing is better Java2D/OGL integration. Java is everywhere and so is OGL. Stop assuming you can solve every problem with plain Java2D and make OGL support a real Java feature.
Anyway, I want to try geometry shader generated particles, that’s my main motivation to write the benchmark. Never done it before and want to see how it feels.
I did some experiments in the Swing/OGL integration area. The last one worked quite good, it uses Scenarios sun.*.EmbeddedToolkit API (which is more or less already a show stopper because of its license) and redirects events from the window to virtual peers. This enables rendering swing components inside JOGL scenes regardless whether the toplevel component is heavyweight or not (GLCanvas). Focus, key events, Overlays everything seemed to work properly.
It is the usual paint to BufferedImage - copy to texture - render as quad implementation - but this time not that hacky.
I know this is not what you asked for with better Java2D/OGL int. but it is still somewhat on topic
EA uses already since several years a proprietary embedded flash renderer for things like game menus etc. - we could get this for free in java…
come on i’m sure we have much more ranting to be doing!
no a/v input for the media stuff in javafx!? sound playback is still not low-latency! still alert dialogs, whats going on!come on, if you don’t shout it wont be a cool thread.
I just thinking out loud isn’t JavaFX targeting to much? How large do we want JavaFX?
I mean soon we will have 3d, JWebPane(correct me if I’m wrong), and what not.
Btw what’s the current size of JavaFX?
Still not employed on JavaFX team!
Cas
IMHO:
not only JavaFX is targetting tooo much, about every new Java API including the Sun JRE are always targetting too much and rather doing less things nice, it do a lot of but very buggy and both make Java World become everyday less compatible.
also I found that the benchmark is a litle meaningless too, lot of benchmark are, because for example JavaFX provide thousands of functionalities and as a generic stuff it usually become slow, pulpcore just run fine on JRE 1.4 so what the meaning of this benchmark if we compare those API on 1.4 JRE ?
so you can only compare two function when they only have a cupple of lines but it is useless to compare two API cause they never provide same functionalities. So finally the benchmark is only relevant to say "if you want to show a lot of bouncing bubble , the way to go is …etc… " but if you want to display cube this is no more true…