JavaFX graphics performance and suitability for advanced animations

[Richard Bair]

Hi John,

> Graphics?  Yes, to a point.  But my post was really about graphics and the
> issues related to performance.  Again, unless those issues are resolved then
> it's not appropriate to state that JavaFX is suitable for "graphics".

You asked what the "full range of applications for which JavaFX is or will be suitable for".

> Then you mention Halo 5.  I have to say the subtext here troubles me
> greatly.  If I read you correctly then you are saying that JavaFX is not
> really suitable for games (at least anything beyond the demands of something
> like Solitaire).  As someone else pointed out, what is point of developing
> 3D support in JavaFX if it is not really suitable for games?  To say it is
> not suitable for games implies that it is not really suitable for *any*
> application that requires performant animations and visualisations.  What
> use then is the 3D API?

That's not fair at all. There are a *lot* of enterprise use cases for 3D, and we get these requests all the time. Whether we're taking about 3D visualizations for medical or engineering applications or consumer applications (product display, etc), there is a requirement for 3D that are broader than real time first person shooters.

Game engines often have very specialized scene graphs (sometimes several of them) as well as very specialized tricks for getting the most out of their graphics cards. When we expose API that allows people to hammer the card directly, then it would be possible for somebody to build some of the UI in FX and let their game engine be hand written (in Unity or JOGL or whatever).

>>> 4.       Is JavaFX more targeted at form-based UIs rather than high
>>> performance graphics?
>> 
>> No.
> 
> Again, good to know but where are all the high-performance JavaFX apps?  So
> far I have seen nothing but form-based apps.  Wouldn't it be prudent for
> Oracle to include a "showcase" app or game that shows us the full
> capabilities of JavaFX with high-performance graphics?
> 
> I am sure I am not alone in feeling that the animation examples in Ensemble
> do very little to promote the graphics capabilities of JavaFX.

Are you offering to contribute? :-)

>> Are your slow examples reproducible? If so we need the test case. Is there
> an issue filed? We can't fix things we can't reproduce.
>> We spend a *considerable* amount of time and energy on performance and for
> the things we're measuring we're doing well.
>> As the saying goes "what's measured, improves". After the switch to gradle
> and the new project layout, one thing I'm going to
>> look at is using JMH[2] in OpenJFX so we can write micro benchmarks and
> have them easy for everybody to run and 
>> contribute to. Our current set of micro benchmarks are based on the
> predecessor of JMH which was the
>> JRockit benchmark suite and was proprietary (hence we cannot just open
> source our existing benchmarks without doing some rewrite).
> 
> All good points.
> 
> However, I am not sure that having me preparing "reproducible" test cases
> will actually help.  In my experience, the Ensemble app already serves this
> purpose.  The choppiness I describe is *always* prevalent when I run the
> animations and transitions in Ensemble (including Ensemble 8).  The only
> variation is in the degree of that choppiness.

Then start with that, something absolutely dead simple like a path animation or rotate transition and lets figure out how to measure the jitter and get it into our benchmark suite.

Richard