JavaFX graphics performance and suitability for advanced animations

[Scott Palmer]

Taking a quick look at the code it seems that the animation time for ball
updates is fixed at 40ms using a Timeline with a single KeyFrame.  So
25fps, half the refresh speed of any known desktop computer display.

brickbreaker/Config.java:40
    public static final Duration ANIMATION_TIME = Duration.millis(40);

 Since this is well below the monitor refresh rate, and I suspect it isn't
synced to the display refresh, you get ugly animation.

I flipped it to 20ms for a quick test and the animation is much smoother,
though there is still the occasional jitter due to not syncing with the
display.

I think a better implementation would use an AnimationTimer.  I believe
JavaFX tries to call them at the display refresh rate?


Scott



On Fri, May 31, 2013 at 10:13 AM, Richard Bair <richard.bair at oracle.com>wrote:

> Have you tried to determine what the FPS is? My guess is that FPS is not
> anywhere near the limit and it is the occasional stutter that is the
> problem, but I'm not certain. Knowing that helps to point in which
> direction to go. The fact that it runs pretty well on a PI is indication
> that it isn't the framerate.
>
> Richard
>
> On May 31, 2013, at 4:26 AM, Scott Palmer <swpalmer at gmail.com> 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
>
>
>
>