3.) It's slightly better to set the timer before ticking rather than after - you don't have to worry about setTimeout() clamping if the callback takes >12ms to run and the precision errors are less of a concern. The easiest way to do this is to setTimeout() before invoking the callbacks assuming that somebody will call requestAnimationFrame() within the ticks, and then if they don't end up doing that call clearTimeout() after running the callbacks.

This comment has been minimized.

Current Chrome (16) supports webkitRequestAnimationFrame but not webkitCancelAnimationFrame (or webkitCancelRequestAnimationFrame). This breaks the polyfill because it starts the animation loop with requestAnimationFrame, but there's no way to stop it. I've patched the polyfill to return the setTimeout in this case

This comment has been minimized.

I ran into an issue with Firefox 10, where mozRequestAnimationFrame is supported, but not an equivalent for cancelAnimationFrame. So I was able to start an animation, but not properly stop it. if cancelAnimationFrame is a deal-breaker for you then https://gist.github.com/1866474 might be more your flavor.

This comment has been minimized.

couldn't you simulate cAF by wrapping requestAnimationFrame in a function grabs the ID and passes in a wrapped function that only calls its inner function if cancelAnimationFrame has not been called with a particular ID? (which you can check by having your fake cancelAnimation set the passed in ID on a private/closure variable object to true, and then checking that key in the wrap function.)
or maybe that's all just too complicated/too much overhead etc.

This comment has been minimized.

I tried this out on an iOS Phonegap project, and it runs at a really terrible frame rate on my iPhone 4. I switched back to using a simple setTimeout and am getting close to 60fps. The timeToCall calculation is not good on iOS.

This also clarifies the code a bit (the previous variable names were a bit confusing), and makes sure that the timestamp passed to the callback is correct, because it is determined (by getting +new Date again) right as the callback is being called.

This comment has been minimized.

@taybenlor yeah, but the semantics of requestAnimationFrame (as far as I can understand from reading the spec; it’s not entirely clear/explicit what time should be passed to the callback) should send the time when it’s actually called into the callback. [Also, I edited my previous comment a bit: was looking at the previous version of the gist when I first wrote it.]

This comment has been minimized.

Maybe it's horribly overkill, but if you can multiple animations at the same time. It could pay of to use a list and avoid multiple setTimeout's, also making sure the requests runs at the same time.
I posted my approach here: https://gist.github.com/4438815

This comment has been minimized.

The rAF / cAF shim above for browsers that don't support it (read: IE9) was completely broken for me. In my app I call cAF if rAF is called before a previous callback completes, otherwise some serious lag happens. With the shim it was basically adding 16 ms for each callback so if a whole bunch of events were fired off, the actual final non-cancelled callback might not happen until many seconds later. Hence, I subtracted the 16 ms for each cAF. This works much better in IE9; the part I changed is as follows

This comment has been minimized.

I know I'm super late to the game here, but I actually needed to adjust this polyfill because I am making use of the time argument -- which mean I not only need to fill the method, I also need to overwrite any window.requestAnimationFrame call that doesn't give me time.

Here's my go (note: I didn't rewrite the cancelAnimationFrame polyfill, so I didn't include it here)

This comment has been minimized.

webkitRequestAnimationFrame is broken in iOS if you try and use it on additional pages, you can reenable it by focusing on the url bar then back to the page. (tested on ios6.1 iPad3)
The code by KrofDrakula fixed the issue for me (although the bug he describes was in an iframe, my issue was with basic page-to-page navigation).https://gist.github.com/KrofDrakula/5318048

This comment has been minimized.

A simpler fix for the problem mizzao pointed out: update lastTime after the timeout instead of immediately, so you never have to undo it. Also fixed to make sure request and cancelAnimationFrame are defined consistently, plus gratuitous style changes.

This comment has been minimized.

A couple people have offered versions that collect multiple callbacks into a list all called for the same frame -- my code should handle the same usage without any extra fuss, assuming multiple setTimeouts with the same target time will get called without too much time in between. (I wonder if they will.)

This comment has been minimized.

FWIW, -o-requestAnimationFrame and -ms-requestAnimationFrame have never been used. Both browsers (IE 10+ and Opera 15+) use the unprefixed version. Firefox supports the unprefixed version since FF23, which was released last August (we are now 3 versions further).
So lines 10-15 can be rewritten to:

This comment has been minimized.

I have created my library after reading all of this shims/polyfills. It includes all improvements and some additional features, like custom frame rate, feature detected raf (required in cases where raf is implemented but just doesn't work), using raf from the iframe, increased performance for multiple parallel animations when using non native version by grouping callback calls and using just one timer ...

This comment has been minimized.

I think that the approach of using new timer for each callback can cause unexpected behaviour.
Say you have several elements you want to hide,
if each hide() will be on its own timer callback, they might get hidden not on the same frame

You can overcome this using callback queue and single timer.
(its not the full polyfill, just the way of work)

This comment has been minimized.

raf (npm) v1.0 was released a few hours ago. It's a CommonJS module (i.e. use it in node or in the browser via browserify) that is loosely based on this gist, but with a polyfill which follows the spec as close as possible.

I believe it's best to use as few requestAnimationFrame instances as possible. I avoided frame rates and delays as they're better utilized outside of the polyfill, (vai the timestamp). Thanks to @darius for the timing tweaks, as well as everyone else on here.

This comment has been minimized.

Hai , i am new to angular2. i have a conflict in loading the angular2 webapp in safari browser. Actually where to use this code in the code so that i can get rid of this browser problem. is this also the solution for improper loading of c3 charts in certain browsers like safari and microsoft edge. please help me out and thanks in advance.

This comment has been minimized.

More suitable for the Angular 4 repo, however if you checkout this JS file and add the script to angular-cli.jsons "scripts": [ ".../path/to/this/file/rAF.js" ] it should load correctly. More info can be found here.