dvlden
dvlden

Reputation: 2462

Do you have to cancel requestAnimationFrame

I am using following snippet from Paul Irish:

// requestAnimationFrame shim & fallback
window.requestAnimFrame = (function () {
    return window.requestAnimationFrame || window.webkitRequestAnimationFrame || window.mozRequestAnimationFrame || function (callback) {
        window.setTimeout(callback, 1000 / 60);
    };
})();

I also saw a polyfill but I did not tested this shim in all browsers yet, so I am unsure wether I will need polyfill or not. Perhaps I won't, saving file size.

I am wondering do I actually need to call cancelAnimationFrame somewhere and if so, guess I would need another shim for it. Something like reversed of above:

// cancelAnimationFrame shim & fallback
window.cancelAnimFrame = (function () {
    return window.cancelAnimationFrame || window.webkitCancelAnimationFrame || window.mozCancelAnimationFrame || function (callback) {
        window.clearTimeout(callback);
    };
})();

Basically I tried to console.log the function that is running within requestAnimationFrame and I can see when logging stops so I guess animation frame is no longer used...

My function step() is ending like this:

if (progress == 1) return;

requestAnimFrame(step);

I really care about this and I am still learning about animations overall. It was painful to create animation for me especially using easing equations. Straight answer will do just fine and if needed to cancel please show me an example how ? Right now I believe that cancelAnimationFrame is used only for manual canceling or some complex animations. Well it's just what I think, I am not sure yet.

Upvotes: 3

Views: 5270

Answers (1)

Steven Lambert
Steven Lambert

Reputation: 5891

cancelAnimationFrame is used to stop an animation from outside the animation function. In your step() example, you're stopping the animation from inside the animation function. Both are viable, but the internal stop is probably more common.

The main reason you would want to use cancelAnimationFrame is if you don't want to take animation cycles calculating when you should stop your animation. If you had multiple cases that could stop an animation, checking each case inside the animation loop is actually less performant than calling cancelAnimationFrame when you set the condition to be true somewhere else.

As an example, let's say that you wanted to stop your animation when progress == 1 as in your example, but progress only get's set to one when the user pauses the game. Since users don't pause the game very often, you're actually wasting clock cycles looking at the variable each frame (even if it's only a few ms). If you also had to check if the user died (progress == 2), or jumped to the main menu (progress == 3), then you would be checking 3 if statements every frame. Since you would already have code that checks for these conditions outside of the animation loop, calling cancelAnimationFrame when the code is run helps your animations run slightly faster.

Upvotes: 6

Related Questions