0

I have an animation loop run by requestAnimationFrame.

On my computer, the time between frames obtained this way are more or less 16.667ms corresponding to 60fps. However, https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame states that it doesn't necessarily run at a fixed speed and may try to match the device screen refresh rate which could be 90 or 120 or more these days.

Now what I want to do is to measure the time between frames and simplify the animation on low performance devices if the hardware can't keep up, in pseudocode:

if (elapsed_frame_time > (1000 / magical_function_to_get_the_target_fps_of_requestAnimationFrame()) {
    animation.particles *= 0.9;
}

I suppose I could just measure it over a few empty requestAnimationFrame ticks to get the approximate nominal time but is there anything in the standard library that would just tell me what the interval or fps should be?

user81993
  • 6,167
  • 6
  • 32
  • 64
  • Does this answer your question? [Controlling fps with requestAnimationFrame?](https://stackoverflow.com/questions/19764018/controlling-fps-with-requestanimationframe) – helloitsjoe Feb 09 '22 at 01:30

1 Answers1

4

No there is nothing that let us know the "optimal" frequency of requestAnimationFrame (rAF).
Even measuring it by checking a few rounds is not an exact science. You may very well be measuring while an other app is eating all the available process of the device, your user may be scrolling the page which may have dramatic influence on rAF, you will definitely have outliers and it will be near impossible to tell between a 59.9Hz monitor and a 60Hz one for instance.

So if you really have to go this route

  • Be sure to use an average FPS, based on a big enough sample and to ignore the first call (because browsers actually execute the callback directly from a non-animated document).
  • Check the callback's timestamp, since this will represent the time the monitor sent its V-Sync signal and shouldn't be influenced by other scripts on the page.
  • Probably wait at least a few dropped frames before intervening.
  • Remember that some users may have dual-monitor systems with various refresh-rates.
  • Expect some edge cases and browser bugs.
Kaiido
  • 123,334
  • 13
  • 219
  • 285