JavaFX graphics performance and suitability for advanced animations

[Richard Bair]

>> Did we try turning cache to true and cache hint to SPEED?
> 
> A simple game I wrote used some basic animation of about 50 nodes with effects applied to them (translucent, blur, sectioned viewports into a large Image) and without caching ran painfully slowly.  Setting caching to true and using cache hints (just on the animated nodes) made a massive performance difference (on a macbook air), it was the difference between a game which was playable and a game which was not (i.e. framerate did not drop to single digits and the air's fan didn't spin up).  
> 
> Turning on caching for select nodes was the easiest and single biggest performance improvement I got for the game.

Is the source for that available?

>> We had an embedded hack-fest a couple weeks ago in which performance on desktop went from 320-800+fps on table view scrolling, which in large measure came down to reducing the number of state switches on the graphics card (and the resulting decrease in the number of OpenGL calls).
> 
> I realize the above statement is to do with internal optimizations, but should I, as a user of the JavaFX API ever have to worry that the way in which I write my user code may result in something like an increased number of state switches on the graphics card?  
> 
> Or should I just be able to ignore that kind of stuff as an implementation detail, kind of like when I drive my car, I press the accelerator and it goes and I don't really need to worry much about how that happened? 
> 
> The difficulty for me here is that I don't know what a state switch on a graphics card is and have no way of knowing whether a particular code path is triggering a lot of switches.
> 
> It seems like an aim for JavaFX is to not require the developer be a low-level mechanic to make things work.

From a high level that is the aim -- relieve the developer of the burden of being a graphics expert. However some things (like the performance difference of a box blur vs. a gaussian blur, and image pixel format differences) are inherent to the problem space. If anything those are issues where the lower level details are leaking up (knowing what algorithm is being used for a blur -- there is a speed / quality tradeoff to be made, but many people wouldn't know off the top of their head which is which between a Box and Gaussian).

Some things (state switches) are also inherent in the medium. We can in some cases decrease this overhead for you, but in other cases we won't be able to and the developer will have to learn this particular set of performance tricks. There is still a place for some high quality JavaOne talks I guess :-)


>> We should never require you to have to follow a 15 point performance plan just to get acceptable performance, or to avoid choppiness
> 
> Nevertheless, an official performance guide would be useful (like Android's: http://developer.android.com/training/best-performance.html).

The docs team has been working on one, but I don't know what the ETA is. In the meantime, we ought to populate the wiki. Anybody want to take an ownership role on that and we can submit performance ideas?

Thanks!
Richard