JavaFX graphics performance and suitability for advanced animations

[Scott Palmer]

Flip the link from Mobile to Desktop at the top.

I think JavaFX could easily handle this.

Scott


On Fri, May 31, 2013 at 12:08 PM, Richard Bair <richard.bair at oracle.com>wrote:

> The link didn't work for me, is there another link? (It came up with a
> page of videos, the top one being video.3gp)
>
> Richard
>
> On May 31, 2013, at 8:46 AM, Daniel Zwolenski <zonski at gmail.com> wrote:
>
> > Just on the topic of what should we expect performance/animation/graphic
> wise, are there technical limitations why jfx can't achieve this exact
> level of quality in animations:
> >
> http://m.youtube.com/#/watch?v=-fNg-qZcIdY&feature=youtube_gdata_player&desktop_uri=%2Fwatch%3Fv%3D-fNg-qZcIdY%26feature%3Dyoutube_gdata_player
> >
> > This is more or less the style of animation that I'd want to use jfx for.
> >
> > So if I wrote the code for this and then ran it side by side with the
> video how far off should the two be?
> >
> > I get that this is a pre-rendered video so it has some advantages but
> the video does not use rapid redraws or complicated particle effects,
> shadows, reflections, etc, like in a FPS game. How close should we expect
> jfx to get to this and which bits are not achievable and why?
> >
> >
> >
> > On 01/06/2013, at 1:32 AM, Scott Palmer <swpalmer at gmail.com> wrote:
> >
> >> Richard, I suspect you made a typo.  I think you mean "*40*ms is a
> really
> >> odd number..." (it was 25 FPS, not 25ms)
> >>
> >> I quickly hacked it to use AnimationTimer and the animation is very
> smooth
> >> now.  Though I didn't make the required changes to adjust the speeds
> based
> >> on the refresh rate.  The quick conversion to AnimationTimer is
> trivial..
> >> but going through and adjusting all the translations and increments to
> be
> >> relative to the time between consecutive frames is something I don't
> have
> >> time for.
> >>
> >> Cheers,
> >>
> >> Scott
> >>
> >>
> >> Scott
> >>
> >>
> >> On Fri, May 31, 2013 at 11:21 AM, Kevin Rushforth <
> >> kevin.rushforth at oracle.com> wrote:
> >>
> >>> **
> >>> Btw, there is a JIRA issue filed against BrickBreaker specifically:
> >>> https://javafx-jira.kenai.com/browse/RT-29801
> >>>
> >>>
> >>> Richard Bair wrote:
> >>>
> >>> Have you tried to determine what the FPS is? My guess is that FPS is
> not anywhere near the limit and it is the occasional stutter that is the
> problem, but I'm not certain. Knowing that helps to point in which
> direction to go. The fact that it runs pretty well on a PI is indication
> that it isn't the framerate.
> >>>
> >>> Richard
> >>>
> >>> On May 31, 2013, at 4:26 AM, Scott Palmer <swpalmer at gmail.com> <
> swpalmer at gmail.com> 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.bair at oracle.com> <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
> 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
> >>>
> >>>
> >>>
> >>>
>
>