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-boun...@openjdk.java.net] On Behalf Of
Michael Paus
Sent: Samstag, 24. Dezember 2016 10:21
To: openjfx-dev@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-boun...@openjdk.java.net] On
Behalf Of Michael Paus
Sent: Freitag, 23. Dezember 2016 17:04
To: openjfx-dev@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-boun...@openjdk.java.net] On
Behalf Of Michael Paus
Sent: Donnerstag, 22. Dezember 2016 17:29
To: openjfx-dev@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.
