Update: Ilmari Heikkinen has written a helpful
Browser Rendering Loop blog entry.
Everything you know is a lie.
OK, not everything. But everything you know about measuring the FPS for your HTML5 game is probably wrong. Turns out that measuring the frame rate, or FPS, for an HTML5 game written in Canvas or WebGL is surprisingly difficult.
Turns out Mozilla has a
window.mozPaintCount available, which should provide an accurate FPS. However, this only works for Mozilla.
A manual way to check for hardware accelerated FPS in Chrome is to grab the Chrome Beta channel (as of posting date) and go to about:flags and turn on FPS Counter. However, on a Mac, acceleration only turns on when using WebGL. So, no way to check FPS for Canvas on Chrome for Mac.
Enter
requestAnimationFrame. This little doozy works its butt off to get your game running at 60hz (in Chrome) or 50-60hz (in Mozilla). Instead of writing your own setTimeout loop, you ask the browser to call your draw function when its ready. Yup, that's right, you're putting your game's draw loop into your browser's hands.
This is a good thing, though. The browser knows when it's painting, so it knows when do call your paint function. This reduces tearing, as the browser can draw at the same time as your monitor's refresh. Also a big win: if the tab isn't visible, the browser won't animate, thus saving CPU and battery.
One small hitch with requestAnimationFrame: Firefox 4 just fixed a bug (as of the date of this post) which gets the frame rate up to acceptable levels, but we'll have to wait for the next push of Firefox to get the fix (yay for autoupdates!)
Moral of the story is: you're probably not accurately measuring your HTML5 game's FPS, and you can only programmatically measure it in Firefox with window.mozPaintCount.
Second moral: Use requestAnimationFrame if your user is on Chrome, and soon Firefox 4.
