JavaFX graphics performance and suitability for advanced animations (BrickBreaker)

[Scott Palmer]

Okay, yes, I generally agree.   I would have to take a crack at coding the
Brick Breaker sample with Transition and Timelines to fully appreciate
it.   Adjusting a transition on-the-fly might make sense, but there are
limitations.  E.g. the Transition's duration is fixed, is it not?  Brick
Breaker is too simple to really benefit from going as low as
AnimationTimer, so as far as "how to write Brick Breaker" goes you're
right.  I guess I'm coming at it from the angle of coding a generalized
game loop.. but JavaFX actually can do a lot of the work for you that you
would typically put in such a game loop.  So I see your point. It would be
a good idea to reduce Brick Breaker to a simpler form when someone has the
time, as showing how little you have to code is yet another benefit to
using JavaFX.  Then it would be appropriate to come up with an example more
suitable for AnimationTimer.

Cheers,

Scott


On Mon, Jun 3, 2013 at 11:03 AM, Pavel Safrata <pavel.safrata at oracle.com>wrote:

>  As I see it, our animation API can be viewed as four levels:
> - simple transitions
> - custom transitions
> - timelines
> - AnimationTimer
>
> If you know how an object will move, you should be fine with the upper
> two. If you want to react on user actions you can still adjust the
> transitions in input event handlers (to change directions), you can also
> have property listeners that will be called every time the transition
> updates the property which is every frame. The benefit of the transitions
> is that they compute the time-based interpolation for you and you don't
> need to do that manually (avoiding the mentioned issue with the patch). If
> there is something complicated that needs to be done in each frame and the
> above is not enough, then yes, AnimationTimer may be the right way. I agree
> this may be the case for many video games, but I don't think it justifies
> for using the low-level API where it is not necessary. If this demo is
> about "how to write brick breaker", then diving right to the deepest API
> level is not really educative. If it is about "how to write a typical video
> game", then I think we should rather produce a typical ShootEmUp game where
> this API usage would fit more naturally. I realize it is easy to say but
> hard to find time for it..
>
> With regards to the pulses - pulse is a sync from scenegraph to render
> tree - it tells to the render tree how the current scenegraph looks like
> and render tree then keeps displaying that state until the next pulse.
> Scenegraph also does some updates during the pulse (yes, layouts fall into
> this category). By default on desktop the pulses have an upper limit of
> 60fps (means 60 pulses per second), without any connection to actual
> display refresh rate. I think (and I'm not certain here) that the pulse
> requests are there only to make sure the next pulse is scheduled (we don't
> schedule pulses if nothing changes).
>
> Pavel
>
>
> On 3.6.2013 15:30, Scott Palmer wrote:
>
>  In this particular example you may be right.  The trajectory of the ball
> can be pre-computed for at least the entire length of the straight line
> that it will travel in. You could go a couple bounces ahead even, to the
> point where the ball would get back to the bottom.  However, that is
> definitely not the typical case for a video game.  Per-frame or per-update
> computations are the norm for video games.  Change the game style to a
> shoot'em up where every frame you need to determine collisions, the
> direction of the player or enemy may change etc, and it actually isn't any
> simpler trying to use a pre-computed timeline.  The calculation of such a
> timeline would be more work.  I think in the general case for a video game,
> AnimationTimer is more likely to apply than other techniques.  It fits the
> basic pattern commonly used and therefore makes better sample code.  There
> is a small problem with Richard's patch though...
>
>  I would like to know a little more about the relation of the "pulse" to
> the refresh rate.  I know that there are places in JavaFX where a "pulse"
> is requested or maybe forced.  Presumably to trigger calculations related
> to general scene graph layout issues.  (I find often that the layout of the
> scene is wrong actually - that is when I do actions that force a refresh I
> will see the layout adjust to a state where it clearly should have been in
> the first place.)
>  One would think that in general one pulse per display refresh would be
> the minimum though.  Anything less means the animation will not be smooth,
> anything more shouldn't cause problems.  The key is that the "now" time is
> used to update any time-based values.  I think Richard's patch to
> BrickBreaker is actually incorrect in this regard, as I don't see the
> actual time passed being used in the calculations.
>
>
>  Scott
>
>  On Mon, Jun 3, 2013 at 7:56 AM, Pavel Safrata <pavel.safrata at oracle.com>wrote:
>
>> Hello,
>> I'm a bit behind with this thread but I want to make a few comments on
>> AnimationTimer as  there is a hidden message in the discussion that
>> AnimationTimer is the way to go.
>>
>> First, AnimationTimer is called in each pulse, which doesn't have much in
>> common with display refresh rate (if I understand the term correctly). More
>> importantly, AnimationTimer is kind of extreme low-level animation API that
>> should not be needed in vast majority of cases. I think a better way to
>> code BrickBraker would be to use a single TranslateTransition for the
>> entire straight part of the ball's trajectory; it would automatically
>> compute the interpolation and sync the position on every pulse, which
>> should have the same result as doing everything manually with the
>> AnimationTimer (but expressed in simpler code).
>>
>> Regards,
>> Pavel
>>
>> On 31.5.2013 22:45, Richard Bair wrote:
>>
>>> I pushed the fix to graphics. Thanks Scott for tracking that down! It
>>> looks 10x better.
>>>
>>> Richard
>>>
>>> On May 31, 2013, at 9:25 AM, Richard Bair <richard.bair at oracle.com>
>>> wrote:
>>>
>>>  Patch attached to https://javafx-jira.kenai.com/browse/RT-29801. I'm
>>>> not seeing any stutter on my Mac, interested to hear the experience on
>>>> Windows.
>>>>
>>>> Richard
>>>>
>>>> On May 31, 2013, at 8:44 AM, Richard Bair <richard.bair at oracle.com>
>>>> wrote:
>>>>
>>>>  Ya I did the same, am now adjusting it so the factor by which things
>>>>> move is better.
>>>>>
>>>>> Richard
>>>>>
>>>>> On May 31, 2013, at 8: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>
>>>>>>> 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> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>
>
>