JavaFX performance for complex visualisations

[John C. Turnbull]

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
80s.

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 oracle.com] 
Sent: Friday, 7 December 2012 06:39
To: John C. Turnbull
Cc: openjfx-dev at openjdk.java.net
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
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.

Richard=