Drop in replacements for setTimeout()/setInterval() that makes use of requestAnimationFrame() where possible for better performance

README

Drop in replace functions for setTimeout() & setInterval() that 
make use of requestAnimationFrame() for performance where available
http://www.joelambert.co.uk

Copyright 2011, Joe Lambert.
Free to use under the MIT license.
http://www.opensource.org/licenses/mit-license.php

requestAnimFrame.js

// requestAnimationFrame() shim by Paul Irish
// http://paulirish.com/2011/requestanimationframe-for-smart-animating/
window.requestAnimFrame = (function() {
	return  window.requestAnimationFrame       || 
			window.webkitRequestAnimationFrame || 
			window.mozRequestAnimationFrame    || 
			window.oRequestAnimationFrame      || 
			window.msRequestAnimationFrame     || 
			function(/* function */ callback, /* DOMElement */ element){
				window.setTimeout(callback, 1000 / 60);
			};
})();

requestInterval.js

/**
 * Behaves the same as setInterval except uses requestAnimationFrame() where possible for better performance
 * @param {function} fn The callback function
 * @param {int} delay The delay in milliseconds
 */
window.requestInterval = function(fn, delay) {
	if( !window.requestAnimationFrame       && 
		!window.webkitRequestAnimationFrame && 
		!(window.mozRequestAnimationFrame && window.mozCancelRequestAnimationFrame) && // Firefox 5 ships without cancel support
		!window.oRequestAnimationFrame      && 
		!window.msRequestAnimationFrame)
			return window.setInterval(fn, delay);
			
	var start = new Date().getTime(),
		handle = new Object();
		
	function loop() {
		var current = new Date().getTime(),
			delta = current - start;
			
		if(delta >= delay) {
			fn.call();
			start = new Date().getTime();
		}

		handle.value = requestAnimFrame(loop);
	};
	
	handle.value = requestAnimFrame(loop);
	return handle;
}

/**
 * Behaves the same as clearInterval except uses cancelRequestAnimationFrame() where possible for better performance
 * @param {int|object} fn The callback function
 */
    window.clearRequestInterval = function(handle) {
    window.cancelAnimationFrame ? window.cancelAnimationFrame(handle.value) :
    window.webkitCancelAnimationFrame ? window.webkitCancelAnimationFrame(handle.value) :
    window.webkitCancelRequestAnimationFrame ? window.webkitCancelRequestAnimationFrame(handle.value) : /* Support for legacy API */
    window.mozCancelRequestAnimationFrame ? window.mozCancelRequestAnimationFrame(handle.value) :
    window.oCancelRequestAnimationFrame	? window.oCancelRequestAnimationFrame(handle.value) :
    window.msCancelRequestAnimationFrame ? window.msCancelRequestAnimationFrame(handle.value) :
    clearInterval(handle);
};

requestTimeout.js

/**
 * Behaves the same as setTimeout except uses requestAnimationFrame() where possible for better performance
 * @param {function} fn The callback function
 * @param {int} delay The delay in milliseconds
 */

window.requestTimeout = function(fn, delay) {
	if( !window.requestAnimationFrame      	&& 
		!window.webkitRequestAnimationFrame && 
		!(window.mozRequestAnimationFrame && window.mozCancelRequestAnimationFrame) && // Firefox 5 ships without cancel support
		!window.oRequestAnimationFrame      && 
		!window.msRequestAnimationFrame)
			return window.setTimeout(fn, delay);
			
	var start = new Date().getTime(),
		handle = new Object();
		
	function loop(){
		var current = new Date().getTime(),
			delta = current - start;
			
		delta >= delay ? fn.call() : handle.value = requestAnimFrame(loop);
	};
	
	handle.value = requestAnimFrame(loop);
	return handle;
};

/**
 * Behaves the same as clearTimeout except uses cancelRequestAnimationFrame() where possible for better performance
 * @param {int|object} fn The callback function
 */
window.clearRequestTimeout = function(handle) {
    window.cancelAnimationFrame ? window.cancelAnimationFrame(handle.value) :
    window.webkitCancelAnimationFrame ? window.webkitCancelAnimationFrame(handle.value) :
    window.webkitCancelRequestAnimationFrame ? window.webkitCancelRequestAnimationFrame(handle.value) : /* Support for legacy API */
    window.mozCancelRequestAnimationFrame ? window.mozCancelRequestAnimationFrame(handle.value) :
    window.oCancelRequestAnimationFrame	? window.oCancelRequestAnimationFrame(handle.value) :
    window.msCancelRequestAnimationFrame ? window.msCancelRequestAnimationFrame(handle.value) :
    clearTimeout(handle);
};

are these shims also designed to work without Paul's window.requestAnimFrame? otherwise i see no point in duplicating the checks that paul already does in his. simply do if (!window.requestAnimFrame) return window.setInterval(fn, delay); at the start.

The shims require Pauls requestAnimFrame() to call the correct vendor prefixed function which is why his code is also bundled. Also, Firefox 5 ships with "broken" support by only providing mozRequestAnimationFrame and not mozCancelRequestAnimationFrame. The checks are important to work around this until this is fixed by Mozilla.

Are these still working correctly with the changes to the API? I am basically doing something like this: and get mycallback never gets called.

var timer = window.requestInterval(mycallback, 60);

Take note that this code will use a global "handle" variable. So, make sure you aren't using it in global namespace, or have to replace it with another name.

For window.requestInterval's loop() function, there is a mistake, which would cause clearRequestInterval() to not work (ie. loop will continue to run indefinitely) if canceling the frame happens to be done within the fn.call() invocation.

It might be better if fn.call() occurs after requestAnimFrame(), not before it. This would allow situations within fn.call() to cancel the latest requested animation frame id (which should be the next frame), and not end up canceling an outdated animation frame id (which is the current frame being executed).

Here it is edited function:
function loop() {
handle.value = requestAnimFrame(loop); // replace this in first line instead! request next frame.
var current = new Date().getTime(),
delta = current - start;

    if(delta >= delay) {
        fn.call();
        start = new Date().getTime();
    }

};

@Glidias I've implemented your suggesting in my fork.

I've also changed requestTimeout to allow passing an argument with the function call.

In order for the requestAnimFrame shim to work in IE9 (and below), the setTimeout fallback should return its handle:

function(/* function / callback, / DOMElement */ element){
return window.setTimeout(callback, 1000 / 60);
};

Please help. Why this case not working?

var time = 1;
var r = requestInterval(function() {
console.log('tick', time, time == 15, r)
if(time == 15) {
clearRequestInterval(r);
}
time++

}, 1000)

But if you type in console clearRequestInterval(r); - this work?

Is this still usefull in 2016 ? I guess not

@kopax why not?

I guess code can be simplified by removing the preffixed code based on the current stats:

http://caniuse.com/#feat=requestanimationframe

Can somebody create an npm package for it?

@hinell See https://www.npmjs.com/package/request-interval

clearRequestTimeout wont work as it is said above

you have param(int|obj) for both clear/cancel function, but it does not allow either a object or integer but just a object. You can put a test case to see rather the argument is a object or integer.

I did a fork and corrected that but when I thank about it, it is more simple to just pass that handle than to explicit pass the number value so maybe the real correction would be to remove that int| from "@param {int|object} fn The callback function"

And I like for you to consider performance.now() would be a better decision than new Date().now();

here are two sources to help you consider this:

performance date now vs date gettime
https://stackoverflow.com/questions/12517359/performance-date-now-vs-date-gettime

performance now vs date now
https://stackoverflow.com/questions/30795525/performance-now-vs-date-now

It to me sound like what you have is correct but we are looking a performance and it seem from what I read, you can get better result with performance and timing with animation using the performance.now() so since we don't really need to know about the exact time and only for a precision of how long it been... So maybe like I said what you have already is better.

I think this is still useful in 2019, but we do not need all the checks for animationFrame functionality, unless you are supporting some seriously old browsers:
https://caniuse.com/#feat=requestanimationframe

i.e. lots of the above code can be stripped out.

I tried animating a drive with Google api v3.
I took a screen shot, it looks very wrong....
Please see image

I've noticed that when switching over from setInterval to requestInterval, my old delay (45 fps, don't judge me, 22.22 ms) was outputting around ~33 fps. Looking into it, this is because the specified delay isn't a multiple of the 60 fps, 16.66 ms delay. To fix this, I used the following:

requestInterval.js ln 23:

start = Date.now() - (delta % delay)

Date.now() is a bit faster, and accounting for the multiple of my delay fixed the issue completely. Without this, I believe even when setting a target delay of 60 fps, 16.66 ms, the actual fps reached would be something like 30-45, since some frames would be skipped at random.

Sorry for bringing back an old thread, just leaving this here for anyone who needs it!