JavaFX Scenegraph Performance Revisited
Prior to the release of JavaFX 1.2, an earlier blog post explained how creating an application with a scenegraph containing a large number of nodes can have performance implications. That entry was subsequently picked up by Java Lobby and recently posted here. Partly because it was a few months old, it resulted in a rash of, shall we say, interesting comments.
As one commenter pointed out, the initial results represent JavaFX performance in the 1.0/1.1 timeframe. JavaFX 1.2 has since been released, and performance has improved substantially. As a case in point, you can click on the image below to run the clock application. This same application, developed and compiled with JavaFX 1.1 can be run from the previous blog post. Further instructions are there.
This application, compiled with JavaFX 1.2 and run on identical hardware, uses about a third of the CPU resources of the original version. Specifically, using OpenSolaris vmstat(1M) to monitor CPU usage, the following average statistics were collected for one minute when the clock display is updated every 10th of a second. The abbreviations have the following meanings:
- us = percentage usage of CPU time in user space
- sy = percentage usage of CPU time in system space
- id = percentage usage of CPU time idling
- The sum of (us + sy + id) should approximate 100%.
And here are the utilization numbers:
|Version|| # Nodes per Digit
|| CPU Utilization
| BulbClockNode JavaFX 1.1
|| 27 BulbNodes
||us: 22% sy: 2% id: 76%|
|BulbClockNode JavaFX 1.2||27 BulbNodes||us: 7% sy: 2% id: 91%|
Yes, performance has improved significantly and will continue to do so. In fact, the JavaFX team is promising even better results with the advent of JavaFX 1.3 (code named SoMa), when considerable refining of the underlying architecture will take place. At this stage in it's lifecycle, it's important to "subscribe" to the JavaFX technology. Advances are coming fast and furious, and they don't promise to slow down anytime soon.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)