JavaFX graphics performance and suitability for advanced animations (BrickBreaker)

[steve.x.northover at oracle.com]

Can you make the changes and verify the results?  BrickBreaker and the 
other samples are supposed to be "how to" examples for people to emulate.

Steve

On 03/06/2013 7:56 AM, Pavel Safrata 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
>>>>>>>
>>>>>>>
>