JavaFX 2.0 bubblemark – part 2

The first post on the JavaFX 2.0 bubblemark created some feedback, most notably an email from the JavaFX engineering team stating in so many words that JavaFX 2.0 has an issue and that is why it per default is not running on full speed. But the remedy should be the magical “-Djavafx.animation.fullspeed=true” option. So without further due the JavaFX bitmap test was run with that option.

So first here is the total view for all 4 tests (the ‘+’ is the fullspeed option):

And the zoomed-in version:

What stands out first is the fact that JavaFX now has the expected curve, and not only that, but it is uncapped. Swing had a 200 FPS maximum because it used a 5ms timer, with 100 balls JavaFX does 900 fps. Secondly it can be seen that the curve is not impressively offset from swing. On visually inspecting the charts, it seems that JavaFX is on average about 5 fps faster than Swing, with the same amount of balls. That still is not what I would expect.

It is clear that the bubblemark test is a somewhat dual benchmark; it not only measures the graphical part, but also the implementation of the collision code. But never the less it is a comparison, after all all the implementations must move the balls and do collision detection. So therefore some of the other test (Flex, Air, etc) were run as well. Some tests didn’t have the option to select the number of balls (the air implementation had 16 hardcoded), some had a maximum of 128 balls and I wanted the fps for 512 balls, so I scaled these numbers according to the JavaFX curve. This means the numbers are not 100% accurate, but I believe representative:

It appears Java and its two Oracle UI libraries are the fastest option by far (unfortunately no SWT implementation is available).

Last but not least, let’s remove the collision detection code from the equation and just keep the ball-moving code, so the graphical part of the test becomes more pronounced. The collision detection has a logarithmic impact on the performance, the moving code only linear. So removing it should make quite a difference:

Again, Swing sticks pretty close to JavaFX. Aside from adding the command line option and commenting out the nested loops in JavaFXTest and BallsTest, the test are identical to the code available in the first blog, so anyone can repeat this easily for himself. The remaining question is: why is there so little difference between Swing and JavaFX? Is it the test? Is JavaFX not very fast?… Or does the ageing Swing demonstrate that grey hairs are no indication for poor quality or speed?

Feedback is welcome.

Update 2011-1128
The optimized Swing bubblemark code that was the basis for the JavaFX version was originally written by Richard Bair, which co-incidentally is now on the JavaFX team. His reply to an email I send roughly comes down to this: Swing also uses hardware acceleration, so it is only logical that it also is fast. Both should be fast. However, further improvements can be achieved if you start using special graphics algorithms and currently Prism [the engine in JavaFX] does not do much of that, there is a lot of potential there. Work on this is scheduled for JavaFX 2.1, 2.2 and 3.0.

In other words; Swing at the moment may be almost as fast as JavaFX, but JavaFX is where growth is possible. One technology is at its peak, the other takes over from there.

About these ads
This entry was posted in Java, javafx, UI. Bookmark the permalink.

3 Responses to JavaFX 2.0 bubblemark – part 2

  1. Pingback: JavaFX News, Demos and Insight // FX Experience

  2. miho says:

    Thanks for your benchmark code! There is one thing that bothers me about JavaFX. Why does the framerate drop if the stage size increases? I created a benchmark based on your code that demonstrates that. All the balls stay in a box that does not change in size. Just the stage size increases. And unfortunately the framerate drops. This is a problem for applications running on big screens such as iMac 27″ (2880×2560).

    Here are my results: http://mihosoft.eu/?p=280

  3. tbeernot says:

    To be honest: I don’t know. In your scenario there is no increase in computation power because of collisions, so one would expect that there would be none or only a minimal difference only based on the larger scene. I’d suggest you ask this question on the forum or mailing list:

    https://forums.oracle.com/forums/forum.jspa?forumID=1385

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s