JavaFX graphics performance and suitability for advanced animations
richard.bair at oracle.com
Tue May 28 17:21:20 PDT 2013
> Animations, particularly with text, were jerky and not real nice, with timing and smoothness issues.
I think this is still the case because of the fact that the text is pixel snapped. Did we try turning cache to true and cache hint to SPEED?
> At this stage I don't think there's much point developing the game code further until the issues it has hit get reviewed by the jfx team. Basically the point of the game was to test jfx performance and on that front, it found jfx to be very poor. Note that I'm using the term 'performance' to mean 'smoothness of user experience' not the more limited and less useful metric of 'framerate'
Lets use performance to mean fps, and choppiness to mean inconsistent framerate. I think being consistent will help keep track of which issues are affecting which manifestation of "visual crappiness" :-)
> Its entirely possible that the problems may be in the game code itself but someone from the jfx team would need to feed back on this, since as far as we could, we used best practices or guessed at them. Part of the point of the project was to get feedback on these best practices from people who understood the internals of jfx.
I generally view it as a failing if the platform allows to write slow apps without you having to go out of your way to make them slow. We should never require you to have to follow a 15 point performance plan just to get acceptable performance, or to avoid choppiness :-). If you're creating a couple hundred thousand nodes when you could have used 100, then ya, its OK if that is slow. If what you're doing is impossible to get good performance even with hand tuned native code, then ya, OK, it is going to be slow. But if you're doing sensible stuff and it is slow (or choppy) then that's not good.
> It is also possible that j8 has improved here but someone would need to run the game code against this. Based on John's comments, it sounds like similar issues are still present.
> I documented the issues in an email several months back (issues are easily reproduced by running the code) and had kind of hoped there might be a little look into it while I was away, but without a bit of noise around the topic I think it lost focus.
Doh, I'm digging through my email history but I'm not seeing it.
> I am happy to help anyone who is interested to reproduce and investigate the issues. Just ask.
That would be awesome and greatly appreciated. I've put on the wiki  several ideas. Some more came up during a performance fest a couple weeks ago. Some of these are in JIRA, the others are showing up there soon.
This query leads to a billion issues or ideas (most are features) and are a good place to look over when thinking about things that could be done: https://javafx-jira.kenai.com/issues/?jql=project%20%3D%20RT%20AND%20labels%20%3D%20performance%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20New)
The biggest thing when doing performance work is identifying the benchmarks. Once we know what we're measuring, it *will* get faster.
More information about the openjfx-dev