[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    RE: AnimationTimer and actual frame rate
From:       "Markus KARG" <markus () headcrashing ! eu>
Date:       2016-12-25 16:22:59
Message-ID: 000c01d25ecb$2ba4ac30$82ee0490$ () eu
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]