JavaFX graphics performance and suitability for advanced animations
swpalmer at gmail.com
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 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
> > like Solitaire). As someone else pointed out, what is point of
> > 3D support in JavaFX if it is not really suitable for games? To say it
> > 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
> > However, I am not sure that having me preparing "reproducible" test cases
> > will actually help. In my experience, the Ensemble app already serves
> > 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.
More information about the openjfx-dev