Oracle has released the revamped JavaFX 2.0 on JavaOne 2011. It’s an interesting step which immediately invokes many questions. What is the target audience for JavaFX? Which technology segment does it aim at? What are the chances it will actually claim a piece of that segment? Is it any good at the segment it is aiming at? Only the future will tell the answers to all the questions. But some can be attempted to be answered today.

First of all a short summary of what I believe JavaFX 2.0 is: JavaFX attempts to be a higher performance graphics framework, with a UI layer on top, able to display different types of media.

“Higher” means that it is not aiming at high end gaming (for example the recently released Battlefield 3 and Call of Duty Modern Warfare 3), but more at the level of platform games like Mario Bros or the fancier and animated user interfaces that some applications have lately.

“Graphics framework” indicates that it is not a UI library in its core (like Swing or SWT), but its designed primarily for drawing, manipulating and animating shapes like circles, rectangles and lines.

“UI layer on top” to note that it does come with a good set of UI controls, that are drawn using the graphics framework and thus can easily be made “fancy”.

“able to display different types of media” means that there is support for playing audio or video streams.

This kind of framework is commonly known as a RIA, or rich internet application, framework.

Having established the technical intention of JavaFX, the first step would be to see if it is any good at what it’s trying to be. This means bringing out the tame racing driver, aka a common frame of reference. For benchmarking a RIA the unofficial first thing to do is throw the bubblemark test at it.

Bubblemark contains a lot of different implementations and because I do not like to reinvent the wheel, it seems a good idea to adapt an existing test to JavaFX 2.0. Naturally there is the JavaFX 1.0 implementation, but since that uses JavaFX script, porting it could be, ahm, more work. The other approach would be to adapt the Swing version and because it is implemented in Java, adapting that may be, ahm, less work. Furthermore it is fair to say that JavaFX will initially appeal to Swing developers, so running both side by side also makes for an interesting comparison.

The Swing (optimized version) Bubblemark code seems somewhat illogically structured, but after a closer look it turned out that most logic was put in the Ball class. Extending that with a JavaFXBall implementation was fairly easy. The Swing version uses a bitmap image of a ball, but testing a full vector JavaFX version is relevant, so in fact two classes were made: JavaFXBallBitmap and JavaFXBallVector.

Next the actual test case. The Swing version is implemented as an Applet, to make life not unnecessary complex at this stage, I chose to quickly rewrite that to use a JFrame and write the JavaFX code to use a regular Scene. A browser embedded version can be made later. Furthermore I wanted to put the results in a graph, so I adapted the test cases to calculate the number of frames per second (after a short warm-up period) and then output that on stderr and then automatically increment the number of balls with 100.

The Swing version uses javax.swing.Timer to move the balls, for JavaFX I decided to use javafx.animation.AnimationTimer. And basically that is it: start the timer, count the frames and see how many are done in a second. Below the test case code:

The first thing that stood out is that AnimationTimer caps the FPS as 60 fps. After an initial confusion this does not seem that bad; we’re not interested in values greater than 60 fps, those are smooth anyhow, but when it gets below. So with a little help from Excel, there is a nice graph:

The result was not what I expected. There seems to be some kind of stepping in the FPS, especially the sudden drop at around 1700 balls; I expected a curve. I reran the test several times, but the results are the same. Naturally I hope people will repeat it on their systems. For reference, I have a 2.4 Ghz quadcore Intel CPU (but the test does not do multi-threading) and a nVidia GTX 560 graphics board (since JavaFX uses hardware acceleration).

So, how about the vector version and the Swing version then? Well, after running and loading them into Excel I got this graph:

Again, not what I expected. I would expect JavaFX to be considerably faster than Swing. Zooming into the part where Swing also breaks the 60 fps barrier:

Swing has the curve I expected and JavaFX does not. The results as a whole are not what I expected and makes me question the Bubblemark test. If you comment out the collision code, the FPS go up. So the question is: what is the Bubblemark code actually testing? The performance of JavaFX or the implementation of the collision code?

For those interested to run the code for themselves: the JFrame version of the Swing test is in the JavaBallsApplet class, the JavaFX version is in the JavaFXTest. Alternating between line 32 and 33 will give the bitmap or vector version.

Your link to BubbleMark isn’t correct: it must not have the www. part, as it leads to another site.
And indeed, you also test the collision algorithm, which isn’t much optimized (all other balls are tested, even if they are far away). A quadtree would help in making this more efficient. Or just don’t check collisions of balls between them, only against walls.
Anyway, it isn’t really important as we want one technology against another, for the same number of balls.

What link are you referring to? I saw one on twitter, FXExperience and Google+.

I think the fact that the collision detection is taking up so much of the CPU time probably is part of the reason why Swing and JavaFX are so close together. I intend to create a graph of the same code without collision detection (both JavaFX and Swing).

I’m not sure optimizing the little math that is done in the collision detection will impact the performance much, considering distance calculation must be done anyhow. And in the case of a quadtree, it must be maintained and modified as well; the balls basically free float, so they move from one quadrant to another.

As I say in the article; we’re not interested in FPS above 60 anyhow, so the capping is not a problem, only unexpected. But as you can see in the “part 2″ blog, the capping and plateaus are due to a behavioral settings of JavaFX.

However, if JavaFX ever wants to do 3D, it must do at least 120 fps (60 for each eye), so the above 60 numbers are interesting for future options.

Dear ,
thanks for that JavaFX performance test, because i wanted to know how to count FPS with JavaFX (its a new API for me, i did things with Java2D/Swing before).
Now i can go further with my program (an isometric demo, i´ll upload it onto my Website)
My site is in german; if get enough time i will make an english translation. ;-)