JavaFX graphics performance and suitability for advanced animations

Scott Palmer swpalmer at
Fri May 31 04:26:23 PDT 2013

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.


On Thu, May 30, 2013 at 11:11 AM, Richard Bair <richard.bair at>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

More information about the openjfx-dev mailing list