JavaFX Particle-o-Rama Thoughts

Update: I have put up a new version of Particle-o-rama (still using my refactored code), but instead of applying effects to each individual partical, I apply the same effect to the group responsponsible for all particles. This, on my computer, is far more performant than Josh’s version, but looks the same (or very similar). </Update>

If you’re reading this blog, you’re probably well aware of Josh Marinacci’s Particle-o-rama project that he put out recently. It’s a simple particle simulator designed to put JavaFX through it’s paces (by throwing lots of independent nodes into the scenegraph). When it came out I was not very impressed by the speed of the animation, so I decided to look into it today. I should note that the video on the page linked to above shows it to be very performant on Josh’s Mac, so I’m not entirely sure why the same application doesn’t work well on my (equally powerful) Vista machine.

I ended up doing a decent refactoring of the code (which is what I tend to do to understand what is going on), but it turns out that the key issue is the use of JavaFX effects to blur the particles. By simply disabling three lines of code, the performance jumps considerably (on my machine a rough guide is by about 400%). This improvement also includes my other refactorings that would have improved the performance a little, but not anywhere near as much as the result of turning off effects.

You can compare my version to Josh’s version.

So, in summary, effects in JavaFX are still in some circumstances slow. If you are experiencing slow-downs in your code, try disabling any effects you have enabled and see if that helps.

Even with the improved speed of my version, it maxes out and starts to become laggy after about 400 nodes are visible. This is obviously not good enough, but it sounds like Sun are putting a lot of effort into improving performance in the next few releases of JavaFX. It will be good to keep testing performance in relation to both my version and Josh’s version of this particle simulator.

For those of you interested in how I cleaned up / refactored Josh’s code, you can see my version here. I kept the same general gist of Josh’s version, but binned a lot of unnecessary code, merged loops where possible, and extracted comparisons to be performed outside of loops where possible. Josh’s original code can be seen here.

4 Responses to “JavaFX Particle-o-Rama Thoughts”

  • Unfortunately, it is the blur that helps sell some effects. For example fire looks very artificial without the blur.

    You could work around it by replacing the vector (I’m assuming) particles with an appropriately blurred bitmap. Not sure what effect that would have on the speed though.

    • I agree that the blur is important, but given the performance impact it had on Josh’s version, it is important for people to know how to improve the performance in their applications. Of course, over time hopefully Josh’s better looking version will become faster than my version, thanks simply to performance improvements in JavaFX itself. Until that time however, there is a need to know how to trade off looks for speed. It will be interesting to see how performance improves in future releases of JavaFX.

      Thanks for your thoughts.

  • This is from a chat with Chris Campbell, graphics guru at Sun. He let me post this as a comment here on his behalf, but it was initially a rushed chat, hence the brevity.

    The short story is that the JavaFX < -> Java2D/D3D pipeline bridge has some inefficiencies related to context switching, and also changing render targets in D3D itself can be quite expensive. So if you have a scene with lots of small objects, and you apply an effect to each one, it can be slow.

    Depending on the visual effect you’re looking for, you can often get better performance by applying a blur to the whole group at once, instead of on each node. May not look right in the case of his demo though.

    And quickly, the way we’re combatting those inefficiencies is two-fold. 1) The new graphics stack shown at JavaOne (“Prism”) doesn’t have any context switching issues like we have with Java2D. (We did the best we could with Java2D’s D3D backend, but there are constraints there that make it tough.) 2) We have tricks to minimize the overhead of D3D/OGL for small operations by falling back on the software paths, which have far less overhead and are still quite fast.

Comments are currently closed.