AnimationTimer and actual frame rate

[Michael Paus]

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.

[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-***@openjdk.java.net] On Behalf Of Michael Paus
Sent: Donnerstag, 22. Dezember 2016 17:29
To: openjfx-***@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.

[Michael Paus]

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

Post by 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-----
Sent: Donnerstag, 22. Dezember 2016 17:29
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.

[Markus KARG]

I assume it is OK for you to use internal APIs? Then you could go with:

com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene)

and let a timer fire one per second to request tracker.getAverageFPS().

Beware not to use any AnimationTimer handlers, as it will reduce FPS, even if the handler method is short.

-Markus

-----Original Message-----
From: openjfx-dev [mailto:openjfx-dev-***@openjdk.java.net] On Behalf Of Michael Paus
Sent: Freitag, 23. Dezember 2016 17:04
To: openjfx-***@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

Post by 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-----
Sent: Donnerstag, 22. Dezember 2016 17:29
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.

[Michael Paus]

Many thanks again.

Post by Markus KARG
I assume it is OK for you to use internal APIs?

Of course it is :-)

Post by Markus KARG
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.

Post by Markus KARG
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?

Post by Markus KARG
-Markus
-----Original Message-----
Sent: Freitag, 23. Dezember 2016 17:04
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

Post by 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-----
Sent: Donnerstag, 22. Dezember 2016 17:29
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.

[Markus KARG]

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-***@openjdk.java.net] On Behalf Of Michael Paus
Sent: Samstag, 24. Dezember 2016 10:21
To: openjfx-***@openjdk.java.net
Subject: Re: AnimationTimer and actual frame rate

Many thanks again.

Post by Markus KARG
I assume it is OK for you to use internal APIs?

Of course it is :-)

Post by Markus KARG
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.

Post by Markus KARG
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?

Post by Markus KARG
-Markus
-----Original Message-----
Sent: Freitag, 23. Dezember 2016 17:04
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

Post by 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-----
Sent: Donnerstag, 22. Dezember 2016 17:29
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.

[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

Post by Markus KARG
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-----
Sent: Samstag, 24. Dezember 2016 10:21
Subject: Re: AnimationTimer and actual frame rate
Many thanks again.

Post by Markus KARG
I assume it is OK for you to use internal APIs?

Of course it is :-)

Post by Markus KARG
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.

Post by Markus KARG
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?

Post by Markus KARG
-Markus
-----Original Message-----
Sent: Freitag, 23. Dezember 2016 17:04
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

Post by 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-----
Behalf Of Michael Paus
Sent: Donnerstag, 22. Dezember 2016 17:29
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.

[Michael Paus]

Yes, that's what I normally observe and when you increase the load on
the graphics pipeline
this is eventually slowed down when a frame rate of 60FPS cannot be
maintained anymore.

Now on my Mac I observe a very strange behavior under certain conditions
where the visible
frame updates drop to something like 1FPS but the AnimationTimer is
still running with
something like 30FPS. So, what I would like to know is whether such a
behavior is normal according
to the design or whether this is a potential bug. I have not yet
observed this behavior on Windows.

Michael

Post by 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

Post by Markus KARG
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-----
Sent: Samstag, 24. Dezember 2016 10:21
Subject: Re: AnimationTimer and actual frame rate
Many thanks again.

Post by Markus KARG
I assume it is OK for you to use internal APIs?

Of course it is :-)

Post by Markus KARG
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.

Post by Markus KARG
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?

Post by Markus KARG
-Markus
-----Original Message-----
Behalf Of Michael Paus
Sent: Freitag, 23. Dezember 2016 17:04
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

Post by 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-----
Behalf Of Michael Paus
Sent: Donnerstag, 22. Dezember 2016 17:29
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.