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.
Comments
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)
Chad: that seems like a good idea.
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...
http://en.wikipedia.org/wiki/Moving_image_formats#50_vs_60_Hz
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.
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^)
(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?
50 will mean dropped frames. Composited windowing systems will run at the refresh rate or they would drop frames.