AnimationTimer and actual frame rate

Markus KARG markus at
Sun Dec 25 16:22:59 UTC 2016

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?


-----Original Message-----
From: openjfx-dev [mailto:openjfx-dev-bounces at] On Behalf Of Michael Paus
Sent: Samstag, 24. Dezember 2016 10:21
To: openjfx-dev at
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] On 
> Behalf Of Michael Paus
> Sent: Freitag, 23. Dezember 2016 17:04
> To: openjfx-dev at
> 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] On 
>> Behalf Of Michael Paus
>> Sent: Donnerstag, 22. Dezember 2016 17:29
>> To: openjfx-dev at
>> 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.

More information about the openjfx-dev mailing list