JavaFX performance for complex visualisations

Richard Bair richard.bair at
Thu Dec 6 11:39:29 PST 2012

> The smoothness issue is a bit baffling.  On my desktop PC (which is
> virtually a super computer and includes the world's fastest GPU), all the
> animations in Ensemble are very "unsmooth", that is to say that even the
> simple Translate transition demo displays a jumpy red ball moving from side
> to side.  It's so jumpy that it looks like I am actually running it on a
> hand-held calculator or similar!  Conversely, the same demo on my 5-year-old
> laptop is "super smooth" and indeed all the Ensemble demos run extremely
> impressively on this machine.  Do you have any ideas on what is causing this
> and/or suggestions on how to improve things?

It could be related to the accuracy of the timer mechanism being used to initiate pulses. Or maybe the drivers not handling vsync timing properly. But I think it is a good example of the problem we're seeing -- it isn't one of performance (i.e.: rendering is fine for your use case I would wager), but rather something else. For example, we've found that on Mac in some tests when profiling using low-level mac graphics tools, that we're easily getting 60fps, and yet some frames are simply not being rendered on the screen. We're not sure why yet.

> Anyway, I am very excited by the question you posed at the end of your reply
> in relation to building a graphics intensive demo application with JavaFX.
> Another thread has started dealing with the type of game or application that
> would be suitable but the thing for me which is most important is that this
> demo *not* be a clone of some simple existing game but rather be truly
> graphics intensive and demanding.  One suggestion was to re-implement
> Asteroids because "If we can't handle an old 8-bit game from the early 80's
> with nice fluid animations then we can give up and go home" but to me this
> would be exactly what *not* to do.  The idea that JavaFX should be capable
> of fluid animations for an old style game is fine but what have we proved if
> the app does indeed run smoothly using JavaFX?  Nothing really.  We *must*
> focus on something which would not have run on an old 8-bit computer.
> Something that would test Flash today on reasonably powered modern machines.
> Something that actually *requires* a UI toolkit as powerful and advanced as
> JavaFX (or is supposed to be).  Otherwise we have not achieved anything.

As Daniel mentioned, I agree we need to do something much more complicated than a tower defender, but we gotta start somewhere and starting on something that requires less up front engineering is a good way to get our feet wet. I intend to host additional "games" in the workspace -- maybe I should have called them "fx-experiments" after the nature of Chrome Experiments. In fact, that is one thing that we could do is start hosting a bunch of ports of chrome experiments to see how they behave and that way have direct comparisons.

But to start with, lets focus on the defender and see how that goes.


More information about the openjfx-dev mailing list