Performance Zone is brought to you in partnership with:

Jim has posted 16 posts at DZone. View Full User Profile

JavaFX Scenegraph Performance Revisited

08.11.2009
| 5600 views |
  • submit to reddit

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.

From http://blogs.sun.com/jtc

Published at DZone with permission of its author, Jim Connors.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Osvaldo Doederlein replied on Tue, 2009/08/11 - 12:07pm

Runs in <1% CPU here. Q6600 CPU, NVidia Quadro FX1700, Vista SP2 32bit, JDK 6u15.

Notice that Solaris is not the best platform for JavaFX; at 1.2 I think it's still in EA quality stage... and the underlying Solaris stack is certainly nothing comparable to Windows in terms of high quality and optimized drivers, etc. This kind of benchmark only makes sense on Windows and MacOSX; the rest just doesn't exist when it comes to desktop. Only reason to do such tests in Solaris is DTrace, but then you didn't use it ;-)

Only if I keep moving the mouse over the digits while it's in that last-minute mode, CPU usage booms to ~20%, very likely because it's doing a lot of transforms or other tricks that cannot benefit from caching because everything changes at every frame. It shouln't be that bad anyway, but the problem is most certainly not the number of nodes.

Thomas Buhr replied on Tue, 2009/08/11 - 7:40pm

Hi Jim,

Thanks for providing this important update, as we can see JavaFX is realizing significate performance increases. Information like this should be posted on a regular basis, may be even at some central site so it is easier to be informed with the progress JavaFX is making.

As JavaFX becomes a more important development platform, some of us with serious interests will continue to probe and raise questions, in order to validate JavaFX's role in our projects.

Best Regards,

Thom

Adam Malter replied on Tue, 2009/08/11 - 10:06pm

The applet comes up, but pressing stop/start does nothing. So while I'd love to give her a whirl, alas.. Running WinXP/JDK1.5.0_15. So, I certainly believe that you guys are working fast and furious, the evident fact that JavaFX is in 'subscription' mode means that it's unusable from a deployment point of view. I believe the bulk of the tension you feel from the Java community is not over the quality of the work, but for the missed opportunity. With the proliferation of multiple languages on the JVM, Android, Air, Silverlight, decent library based Scenegraphs, and most of all incredible leaps in html/browser based functionality, there is no possible way for JavaFX to be a category owner. Even if you waved your magic wand and pushed out a perfect release with two years of planned features, market fragmentation would mean it would be but a slice of the overall ecosystem. The world looks much different from two years ago. Even the more mature Air and Silverlight (and all the deployable declarative solutions) seem to be out of favor. The case for requiring a specific 'Rich Internet Application' language looks weaker now than ever. I offer as proof that the most lucrative and popular 'RIA' language (Well, lets call it RCA, Rich Connected Application) is Objective-C, a language far further from the declarative style of JavaFX (and Air, et. al). Developers just do not need, nor seem to care one way or another if the language is declarative. Instead, predictable performance, rich libraries, and a good developer and user installation base seem most important. While Java offers most of this (although our browser client deployer is still scary at best to use. I do notice that the example app was a jnlp and not an applet), JavaFx for now only offers a one way integration with Java, and loses all the advantages in mature IDE's, and other development goodies. Java, the 'language' GUI toolkit has clearly languished, seemingly from the engineering effort for JavaFx. Not doubt that Java2d and Swing have received some 'friendly fire' benefits from JavaFx, but it's not enough to make the platform feel cutting edge. All the super cool interesting stuff is locked away behind JavaFx, unusable to the millions of day to day Java programmers who have no desire to learn a new (and most probably, better, but who cares about better) language. So, while I cannot speak for all the 'JavaFx die' commentators, I will opine that it's not out of spite, or respect for very serious effort that has been done - but for the wasted opportunity this fork has taken us. The JavaFx effort could have been a new simplified graphics library, and perhaps some language baubles in JDK 7, and then, without thos waste of a new compiler, and constant evangelizing to the dis-affected, Sun could have pushed the envelope. Instead, we have WidgetFx, which is using 45megs of memory on my box right now compared to Rainmeter using 450k, and doing about a third as much. Stop. Stop now. Take all this effort and put it into the JVM, leave the language to people like Ola Bini, and become the provider of the one and only virtual machine worth having. Or, continue to explore this culdesac. Rant mode off.

Coffee Jolts replied on Wed, 2009/08/12 - 11:32am

The performance is still unacceptable. I have a simple test for you to take any time someone from the JavaFX camp claims that performance has improved.

 1. Visit this link: http://javafx.com/samples/PathAnimation/index.html
 2. Shake your head slowly while watching the car lurch along the road while the animation tears.

I was all in for JavaFX. I wanted it to be great, but the execution in terms of performance has been awful. How does Sun expect anyone to write a RIA on top of a platform that can't animate?

Will Jordan replied on Wed, 2009/08/12 - 3:58pm

3. Next, visit this link for a ridiculous comparison to an RIA platform that actually works decently, all built on top of existing Java applet frameworks: http://www.interactivepulp.com/pulpcore/pathmotion/

4. Now visit this link, which shows applet developed in Scala (ie, non-Java language): http://www.interactivepulp.com/pulpcore/scalalanguage/

5. Shake your head even more slowly.

Osvaldo Doederlein replied on Wed, 2009/08/12 - 5:20pm

I checked (again) the PathAnimation demo, and the PulpCore path animation demo, and they are indistinguishable for me. Same animation smoothness. CPU usage is higher fo PulpCore. Both tested on a now pretty lowly laptop (T7250, 2G RAM, GeForce 8400M - can't run most games published in last 5 years decently). Running Windows 7, tested with both JDK 6u16 and 7b68.

I'm not shaking my head.

Jim Connors replied on Wed, 2009/08/12 - 5:24pm in response to: Osvaldo Doederlein

With the 1.2 version of the application, I get comparable results on a state-of-the-art Toshiba (<1% CPU) laptop running Vista SP1, JDK 6u15.  The original rationale for running the application on an old laptop was as follows:

1. A slower/older device would exaggerate the performance differences.  There may appear to be no performance issues on a modern desktop/laptop, that is until the application is migrated to a mobile device which is much more constrained.

2. With regards to Solaris and JavaFX you are correct, it's not nearly as optimized as the Windows stack.  Again the point was to demonstrate how node count can influence performance.  This seemed to be an ideal platform.  In addition, and I admit a whole lot of bias here, Solaris/OpenSolaris has nice instrumentation.  Even the rudimentary vmstat(5) can produce quite meaningful data.  From a Windows perspective, perhaps it's just due to ignorance, I found the performance data to be erratic. 

Osvaldo Doederlein replied on Wed, 2009/08/12 - 7:40pm in response to: Jim Connors

The bad performance you see in your old perf may be caused by an unsupported GPU, or by the early status of Solaris port, but it's certainly not caused by the scene graph / number of nodes as that part of the JavaFX runtime is pure Java; so, you shouldn't see different behavior. The perf bottleneck should be in the rendering process (not the same thing as the scene graph), perhaps even in Java2D.

Dmitri Trembovetski replied on Thu, 2009/08/13 - 11:19am

FYI, JavaFX 1.2 on Solaris and Linux doesn't use any hw acceleration at all (effects or not) by default unless Java2D opengl pipeline is enabled (even then the benefits may not be all thatgreat).

 

Also, you may get slightly better results on Solaris/Linux by setting -Dsun.java2d.pmoffscreen=false .

 

Dmitri

 

Osvaldo Doederlein replied on Thu, 2009/08/13 - 5:41pm in response to: Dmitri Trembovetski

FYI, JavaFX 1.2 on Solaris and Linux doesn't use any hw acceleration at all (effects or not) by default unless Java2D opengl pipeline is enabled (even then the benefits may not be all thatgreat).

Very important info, this should be present in the Release Notes (just checked - it's not), so all Linux hackers who are trying JavaFX won't be put down by terrible performance...

 

kelly jason replied on Thu, 2009/08/13 - 9:40pm

Replica handbags online shop , a sales outlet specialized in supplies the Luxry brand of Louis Vuitton or LV designer replica bags, handbags, citybags,wallets,purses,clutches and luggage.the Category Content of Damier Azur,Damier Canvas,Damier Geant Canvas,Damier Griphite,Epi Leather,Mahina Leather,Monogram Canvas,Monogram Denim,Monogram Dentelle,Monogram Multicolor collection and so on... the various style and colorful!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.