AnimationTimer and actual frame rate

[Kevin Rushforth]

A running AnimationTimer class will cause pulses to be scheduled 
continuously, but they should still be limited to no more often than 
1/60 sec (unless you are overriding it with system properties).

-- Kevin


Markus KARG wrote:
> Merry Christmas,
>
> my personal observation when performaning an EU-fundet power consumption study was that once an (even no-op implementation!) AnimationTimer was registered, the CPU load increased by several percent _permanently_ on our lab machine. In contrast, with key frame animation, the CPU load stayed at zero percent but showed scattered peaks. Unfortunately I cannot tell you the actual JavaFX-internal reason for sure, but I assume that AnimationTimer is called at maximum possible CPU speed (i. e. more or less an endless loop) while the animation classes update only once per _pulse_ (i e. more or less 60 FPS).
>
> It feels like (but this might be a false detection of mine; I did not check the source code) as the pure _registering_ of an AnimationTimer would enable JavaFX to actually run some JavaFX-internal code "undelayed", while _just_ using animation classes do not run that same code before the next _pulse_ (possible by using timer interrupts set to the next 1/60s).
>
> It would be great if the JavaFX team could confirm this difference between AnimationTimer and animation classes?
>
> -Markus
>
> -----Original Message-----
> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Michael Paus
> Sent: Samstag, 24. Dezember 2016 10:21
> To: openjfx-dev at openjdk.java.net
> Subject: Re: AnimationTimer and actual frame rate
>
> Many thanks again.
>
> Am 23.12.16 um 18:18 schrieb Markus KARG:
>   
>> I assume it is OK for you to use internal APIs?
>>     
> Of course it is :-)
>   
>>   Then you could go with:
>>
>> com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene)
>>
>> and let a timer fire one per second to request tracker.getAverageFPS().
>>     
> I'll give that a try as soon as my family lets me.
>   
>> Beware not to use any AnimationTimer handlers, as it will reduce FPS, even if the handler method is short.
>>     
> Is the AnimationTimer handler more critical in this respect than any of the built-in animations?
>   
>> -Markus
>>
>> -----Original Message-----
>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On 
>> Behalf Of Michael Paus
>> Sent: Freitag, 23. Dezember 2016 17:04
>> To: openjfx-dev at openjdk.java.net
>> Subject: Re: AnimationTimer and actual frame rate
>>
>> Thank you. That explains a lot of what I am observing but it also makes me wonder how you could effectively measure the actual frame rate because that's what you are normally interested in.
>> Michael
>>
>> Am 23.12.16 um 09:15 schrieb Markus KARG:
>>     
>>> AnimationTimer is fired once per "planned" frame (i. e. running at maximum possible FPS), not per "actually rendered" frame. JavaFX contains a lot of optimizations. For example, a boolean property animated over time to switch from false to true will only imply a single modification, hence only one frame is actually rendered.
>>> -Markus
>>>
>>> -----Original Message-----
>>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On 
>>> Behalf Of Michael Paus
>>> Sent: Donnerstag, 22. Dezember 2016 17:29
>>> To: openjfx-dev at openjdk.java.net
>>> Subject: AnimationTimer and actual frame rate
>>>
>>> Hi all,
>>>
>>> for quite a while now I am observing a strange behavior when running 
>>> some
>>>
>>> JavaFX graphics tests. The scenario is very simple. I am running some 
>>> animation
>>>
>>> which puts some load onto the graphics engine and I am trying to 
>>> measure the
>>>
>>> frame rate via an instance of an AnimationTimer. When I increase the 
>>> load high
>>>
>>> enough I reach a point where the indicated frame rate is just 60FPS 
>>> or even a bit
>>>
>>> lower but the observed frame rate on screen has already dropped to 
>>> something
>>>
>>> like 1-2 FPS. So what I observe is that the AnimationTimer is running 
>>> much faster
>>>
>>> than the updates of the graphics. How can that be? Does anybody have 
>>> an explanation
>>>
>>> under which circumstances this can happen? Or is this behavior a bug which I should report?
>>>
>>> Just some puzzle for the boring Christmas holidays :-)
>>>
>>> Merry Christmas to all of you
>>>
>>> Michael
>>>
>>> PS: My system is a MacBook Pro with NVidia graphic card.
>>>
>>>
>>>       
>
>
>