Limit the frame-rate being targeted with requestAnimationFrame

limitLoop.js

/*

limitLoop.js - limit the frame-rate when using requestAnimation frame
Released under an MIT license.

When to use it?
----------------
A consistent frame-rate can be better than a janky experience only 
occasionally hitting 60fps. Use this trick to target a specific frame-
rate (e.g 30fps, 48fps) until browsers better tackle this problem 
natively.

Please ensure that if you're using this workaround, you've done your best
to find and optimize the performance bottlenecks in your application first.
60fps should be an attainable goal. If however you've tried your best and
are still not getting the desired frame-rate, see if you can get some mileage
with it.

This type of trick works better when you know you have a fixed amount
of work to be done and it will always take longer than 16.6ms. It doesn't
work as well when your workload is somewhat variable.


Solution
----------------

When we draw, deduct the last frame's execution time from the current 
time to see if the time elapsed since the last frame is more than the 
fps-based interval or not. Should the condition evaluate to true, set 
the time for the current frame which will be the last frame execution 
time in the next drawing call.

Prior art / inspiration
------------------------
http://cssdeck.com/labs/embed/gvxnxdrh/0/output
http://codetheory.in/controlling-the-frame-rate-with-requestanimationframe/
*/

var limitLoop = function (fn, fps) {
 
    // Use var then = Date.now(); if you
    // don't care about targetting < IE9
    var then = new Date().getTime();

    // custom fps, otherwise fallback to 60
    fps = fps || 60;
    var interval = 1000 / fps;
 
    return (function loop(time){
        requestAnimationFrame(loop);
 
        // again, Date.now() if it's available
        var now = new Date().getTime();
        var delta = now - then;
 
        if (delta > interval) {
            // Update time
            // now - (delta % interval) is an improvement over just 
            // using then = now, which can end up lowering overall fps
            then = now - (delta % interval);
 
            // call the fn
            fn();
        }
    }(0));
};

test.js

/*
Feel free to play with this over at http://jsfiddle.net/addyo/Y8P6S/1/.
You can either use the Chrome DevTools Timeline or FPS counter to confirm
if you're hitting a consistent fps.
*/

// rAF normalization
window.requestAnimationFrame = function() {
    return window.requestAnimationFrame ||
       	window.webkitRequestAnimationFrame ||
		window.mozRequestAnimationFrame ||
		window.msRequestAnimationFrame ||
		window.oRequestAnimationFrame ||
		function(f) {
			window.setTimeout(f,1e3/60);
		}
}();

// define a reference to the canvas's 2D context
var context = television.getContext('2d');
       
// create a buffer to hold the pixel data
var pixelBuffer = context.createImageData(television.width, television.height);

function drawStatic() {
        var color,
            data = pixelBuffer.data,
            index = 0,
            len = data.length;
    
        while (index < len) {
            // choose a random grayscale color
            color = Math.floor(Math.random() * 0xff);
            
            // red, green and blue are set to the same color
            // to result in a random gray pixel
            data[index++] = data[index++] = data[index++] = color;
            // the fourth multiple is always completely opaque
            data[index++] = 0xff; // alpha
        }
        
        // flush our pixel buffer to the canvas
        context.putImageData(pixelBuffer, 0, 0);

};


limitLoop(drawStatic, 30);

@Kouty I think I see my misunderstanding, here we're solely interested in setting a ceiling for frame rate rather than both a ceiling and a floor?

It is not just a matter of a ceiling and a floor. Here we are interested in making requestAnimationFrame work very similar to setInterval.
Any other feature atop the simplest implementation is an opinionated implementation.

What I mean is that one can build her own implementation based on a basic requestAnimationFrame according to the need she has. Each non basic implementation has its pros and cons.

For example, if you are implementing a real time multiplayer game, you need the rendering to be synchronized with the latest data from the server, so a game-loop in this case should sacrifice fluidity in rendering (skipping frames) in order to show what is happening right now.
On the other hand, a simple graphic animation probably would prefer to be smooth (avoid skipping frames) rather than having each frame perfectly synchronized.

What you propose, if I got it right, is to call the "animation" callback n-times to avoid skipping frames. This is one of the possible game-loops implementation.
A typical game-loop will not only call as soon as possible the "animate" callback to avoid skipping frames, but it will provide 2 callbacks, one that should be very light, called ideally each frame of the rendering, another, less light weighted, called with a much lower frame-rate to update the physics, for example.

Just calling the "animate" callback for each skipped frame, is not enough. What happens if your computer is not fast enough to compute the "animate" callback at the desired frame-rate? A naive implementation (just compute the number of skipped frames and call "animate") will stuck the browser and render the whole web app unusable.

In a few words, the question of this Gist could have been: "How do I implement a loop based on requestAnimationFrame so that it works very similar to setInterval?"

love your work dude thank you