Sorry, read the list out of order. Is Brick Breaker something that we
should concentrate on?
Steve
On 31/05/2013 7:26 AM, Scott Palmer wrote:
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.
Scott
On Thu, May 30, 2013 at 11:11 AM, Richard Bair <richard.b...@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
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
