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.