Skip to content

Instantly share code, notes, and snippets.

Last active November 15, 2022 03:52
What would you like to do?
Limit the frame-rate being targeted with requestAnimationFrame
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
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.
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
var limitLoop = function (fn, fps) {
// Use var then =; 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){
// again, 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
Feel free to play with this over at
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) {
// 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 =,
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);
Copy link

bnwa commented Sep 15, 2022

@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?

Copy link

Kouty commented Sep 18, 2022

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?"

Copy link

love your work dude thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment