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. >> >> >
