Tuesday, 17 August 2010

The mozRequestAnimationFrame Frame Rate Limit

A few people have been playing with mozRequestAnimationFrame and noticed that they can't get more than 50 frames per second. This is intentional, and it's a good feature.

On modern systems an application usually cannot get more than 50-60 frames per second onto the screen. There are multiple reasons for this. Some of them are hardware limitations: CRTs have a fixed refresh rate, and LCDs are also limited in the rate at which they can update the screen due to bandwidth limitations in the DVI connector and other reasons. Another big reason is that modern operating systems tend to use "compositing window managers" which redraw the entire desktop at a fixed rate. So even if an application updates its window 100 times a second, the user won't be able to see more than about half of those updates. (Some applications on some platforms, typically games, can go full-screen, bypass the window manager and get updates onto the screen as fast as the hardware allows, but obviously desktop browsers aren't usually going to do that.)

So, firing a MozBeforePaint event more than about 50 times a second is going to achieve nothing other than wasting CPU (i.e., power). So we don't. Apart from saving power, reducing animation CPU usage helps overall performance because we can use the free time to perform garbage collection or other house-cleaning tasks, reducing the incidence or length of frame skips.

We need to do some followup work to make sure that on each platform we use the optimal rate; modern platforms have APIs to tell us the window manager's composition rate. But 50Hz is almost always pretty close.

This all means that measuring FPS is a bad way to measure performance, once you're up to 50 or more. At that point you need to increase the difficulty of your workload.



Posted by Robert at 10:49 PM
Labels:

15 comments:

  1. i agree (and support) wholeheartedly..
    but just maybe you could up this to 60fps (by default, if not detected to be otherwise), as i suspect it might be the most standard refresh rate today (most notebook panels use this by default, plus the HDTV stuff)
    ReplyDelete
  2. "Pretty close" isn't good. Framerates that are close but not equal cause judder. If the display is running at 60Hz, rendering at a consistent 30Hz may look better than 50Hz (with a 10Hz beat frequency of missed frames).
    ReplyDelete
  3. Shouldn't 60 be the max? It seems far more standard than 50.
    ReplyDelete
  4. Robert O'CallahanAug 17, 2010 06:17 AM
    Anonymous: yeah, we'll get it right, but in the meantime whatever we do will be no worse than current JS apps that basically choose random numbers.
    Chad: that seems like a good idea.
    ReplyDelete
  5. I should have mentioned that I love the idea of mozRequestAnimationFrame, by the way. Keep it up!
    ReplyDelete
  6. Just to mirror what's already been said, 60Hz is a far more common refresh rate. It would be a much better fall-back than 50Hz when the refresh rate can't be detected.
    ReplyDelete
  7. [forgot to sign the Anonymous comment above]
    Thanks, and I should have also mentioned that mozRequestAnimationFrame is awesome, especially for Canvas (WebGL!). Hopefully it can be standardized. Something similar might be useful for audio rendering via the Audio Data API too...
    ReplyDelete
  8. There's no real advantage to choosing 60 Hz vs. 50 Hz. About half the world uses multiples of 25 Hz (PAL/SECAM) and about half the world uses multiples of 29.97 Hz (NTSC) and another fraction uses multiples of 30 Hz (NTSC, non-dropframe). Film is 24 fps which doesn't divide evenly into 50 or 60 or 59.94 anyway. So, you'll inevitably have to interpolate no matter what base you choose. So, I say 50 is a fine choice.
    http://en.wikipedia.org/wiki/Moving_image_formats#50_vs_60_Hz
    ReplyDelete
  9. How about the frame count so that it is not only synced on time but also frame count. If one is doing interactive animation, frame count is more important than time. time is how good it looks, count is how well it works correctly. Just my 2 cents worth.
    ReplyDelete
  10. Robert O'CallahanAug 19, 2010 04:14 AM
    I don't understand how you would use frame count.
    ReplyDelete
  11. reply to Chris Dolan:
    It is not correct that half the world uses 50hz for computer monitors, you are talking about television systems, that is something different. Also in europe and other "PAL countries" 60 hz is more or less standard for computer monitors (I live in europe).
    So I suggest just as several others that this limit is set to 60 fps instead.
    ReplyDelete
  12. What is needed is a unique way to identify which frame is currently being displayed. I'm not going to do this in particular but here is an example:
    Say you have a traditional slots game with 3 slots rolling by showing the different fruit at different rates. 2 things need to be done when the player hits the 1 armed bandit.
    a) adjust all frames to the closest top of slot
    (align)
    b) know which frame to know how to score it.
    So anytime there is a need for fine adjustment of which frame is being displayed or how that frame relates to a user input, then you need this knowledge.
    Thanks ;8^)
    ReplyDelete
  13. if (!window.mozRequestAnimationFrame) {
    (function () {
    var funs = [],
    timer = null,
    timeStamp,
    ft = false;
    function onTimer() {
    ft = true;
    timer = null;
    timeStamp = +(new Date());
    var x = funs,
    l = x.length, i;
    funs = [];
    for (i = 0; i < l; i++) {
    x[i](timeStamp);
    }
    ft = false;
    }
    window.mozRequestAnimationFrame = function(fun) {
    funs.push(fun);
    if (timer === null) {
    timer = window.setTimeout(onTimer, Math.floor(1000 / 60));
    }
    };
    window.mozAnimationStartTime = {
    valueOf: function() {
    if (!ft && timer === null) {
    timeStamp = +(new Date());
    window.mozRequestAnimationFrame(function() { });
    }
    return timeStamp;
    }
    };
    }());
    }
    What do you think?
    ReplyDelete
  14. Robert O&#39;CallahanJan 23, 2011 01:42 PM
    That's a good workaround for browsers that don't have equivalent functionality. It doesn't give you the benefits of requestAnimationFrame of course (such as automatic reduction in CPU usage for background tabs).
    ReplyDelete
  15. 50 hz is too low, Make it 60 as that is what most in North America use for their monitors.
    50 will mean dropped frames. Composited windowing systems will run at the refresh rate or they would drop frames.
    ReplyDelete

Subscribe to: Post Comments (Atom)