JavaFX graphics performance and suitability for advanced animations

[steve.x.northover at oracle.com]

Sorry, read the list out of order.  Is Brick Breaker something that we 
should concentrate on?

Steve

On 31/05/2013 7:26 AM, Scott Palmer wrote:
> Speaking of poor animation in Ensemble...
>
> Is anyone able to run Brick Breaker without choppy animation or poor
> framerate performance on the ball?
>
> Now, I suspect the issue there is in the balls animation implementation in
> the application rather than the JavaFX framework, as the bat moves smoothly
> when I move the mouse, but the overall perception of JavaFX performance for
> this demo app is not good. I would go so far as to say that Brick Breaker
> has had the opposite effect it was intended too - simply because the
> animation of the ball is not smooth.  That's something that would run
> smoothly on a Commodore 64,yet the last time I tried it (5 minutes ago)
> with JavaFX 8.0-b91 on a quad-core 3GHz Windows 7 box with a decent NVIDIA
> card, it didn't run as smoothly as I would expect.  Just a single ball with
> a shadow bouncing around the screen seemed to have a low framerate and the
> occasional skipped frame.  It just didn't look that great.
>
> The fact that Brick Breaker ships as a sample app from Oracle and it's
> animation looks bad is harming JavaFX's reputation in my opinion.  I think
> it could run much better on the existing JavaFX runtime.  The simple
> animations in the Ensemble app run much smoother for example.
>
>
>
> Scott
>
>
> On Thu, May 30, 2013 at 11:11 AM, Richard Bair <richard.bair at oracle.com>wrote:
>
>>> 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).
>
>
>
>>> 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