JavaFX performance for complex visualisations

John C. Turnbull ozemale at
Thu Dec 6 12:15:21 PST 2012

Yes, rendering itself is fine on the power machine.  And I don't think it's
a driver issue because OpenGL applications and other Direct3D applications
perform blindingly quickly without any jumpiness.  It's really just running
JavaFX animations that makes the machine look like something from the 70s or

As for the demo app, tower defence it is then.  I think it will be very
valuable to have a nice, impressive demo app/game as part of Ensemble or as
a separate demo in itself.  I fear that many potential JavaFX developers
don't get past Ensemble because they see nothing there that resembles what
they are trying to do with it.  Eventually we really need to have a
kick-arse graphics and sound demo that would be difficult to implement using
any other technology.

-----Original Message-----
From: Richard Bair [mailto:richard.bair at] 
Sent: Friday, 7 December 2012 06:39
To: John C. Turnbull
Cc: openjfx-dev at
Subject: Re: JavaFX performance for complex visualisations

> 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
> 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
> Something that actually *requires* a UI toolkit as powerful and 
> advanced as JavaFX (or is supposed to be).  Otherwise we have not achieved

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