Forums » Code » requestAnimationFrame patch

I'm on a laptop, so it's very important that the CPU not be churning away when I'm not actively using the game (both for battery life and my lap!). I saw a previous thread regarding requestAnimationFrame in the git repo, but I guess that never made it past a test phase.

Anywho, I made my own tonight, and figured I'd share it. I tested it using the jumpandrun and box2d examples. It's a git diff patch, since the changes are just a bit too complex to paste in here (it would basically end up with me pasting whole files, which is not good). It's only a few small changes, which are pretty obvious from the diff if you wanted to apply it manually.

Here it is:

https://gist.github.com/1255534

It includes Paul Irish's requestAnimFrame polyfill, and also allows for non-requestAnimationFrame use (i.e. the standard setInterval Impact uses) by setting ig.system.raf to false in your main init function.

I'm new here, so if there is a better way to do this, please let me know!

Dominic already investigated it and apparently it causes some issues as it is not widely / well supported in new browsers.

Well, I'd love to hear what those issues are. The patch I created uses setTimeout as the fallback, so I'd be VERY surprised if there were cross-browser issues.

When I last tested it, the implementation of requestAnimationFrame showed no benefit at all in Chrome and was really buggy in Firefox:

It's currently capped at 1000/(16 + N) fps, where N is the number of ms it takes your callback to execute. If your callback takes 1000ms to execute, then it's capped at under 1fps. If your callback takes 1ms to execute, you get about 60fps.

~ http://paulirish.com/2011/requestanimationframe-for-smart-animating/

I believe this is fixed now; I'll have a closer look at it again. Thanks for the patch!

Btw.: for background tabs setInterval is capped at 1fps by all(?) browsers. So the only benefit of requestAnimationFrame that remains is, that the game will stop when it's scrolled out of view. More ranting about it in my blog.

I didn't realize that setInterval/Timeout now capped at 1fps for background tabs... a quick check confirmed that you are correct. The Firefox RAF bug is definitely fixed, I think that was only in their first implementation.

Technically, RAF is supposed to allow the browser to optimize the actual painting behavior, so there could still be benefits there, but it's tough to say, given that Impact (and most other JS engines, I believe) does not separate the drawing from the game update timestep. But that involves Web Workers and much more complex code in general (it's also a bit of a rabbit hole... ).

Thanks for the blog link, I'd missed that when it was originally posted, and it was very informative!

I just applied this patch to a game I'm working on that at any given moment has 100+ entities on the screen at once, each running through their own animations. I saw a jump from 20-30fps to 40-50fps in the current non-nightly-build releases of Safari, Chrome, and Firefox (latest MacBook Pro running Lion).

I've not yet tried to compare the the differences of not using RAF vs. using it in Mobile Safari, but I suspect the results will be in favor of RAF by at least a little.