Question 210131 in Javascript Question posted in
A very good W3school tutorial can be found here.

Javascript – Does cancelAnimationFrame clear any existing requestAnimationFrame queues?

Does cancelAnimationFrame completely removes all the queued up animation logic?
For example, lets say the logic was complicated and my screen was doing 60FPS. the time it took to complete the entire logic per frame, lets say is 50ms. That is much more than 16.66667ms which is the minimum to maintain 60FPS.
If each frame takes 50ms in a total of 60 frames, there would be a build up of the animation logic queue. right?
Normally, at 60fps, with 60 frames, the entire animation should take 1 second. Right?
But with my animation logic, it will take 3 seconds total to complete the animation.

Let’s assume, after I start the animation at t0, and I wait until t1.5 while animation is ongoing, and I run the cancelAnimationFrame function, will it stop the animation right then and there? Or will it complete the entire animation until 3 seconds have passed?

What about if I run the cancelAnimationFrame function at t0.5? will it stop the animation right then and there? Or will it complete halfway of the animation until 1.5 seconds have passed?

Tags:

2

Answers


  1. 0

    JavaScript’s requestAnimationFrame function runs a function each time a new frame is rendered.

    let x = 0;
requestAnimationFrame(() => {
  x = Math.random();
})

    In this example, the x variable changes it’s value before each frame is rendered.

    The clearAnimationFrame function stops this pre-render call loop, so after clearAnimationFrame(); is called in this example, the x variable won’t change until requestAnimationFrame(); is called again with the same function.

    Note: A browser tab can have only one requestAnimationFrame function at a time.

    Login or Signup to reply.
  2. 0

    No cancelAnimationFrame(id) doesn’t stop anything.

    What it does is it removes the queued callback corresponding to the passed id from the list of animation frame callbacks, so that this callback (and only this one) is never called.
    However if the callback has already been executed, or if it’s being executed, when cancelAnimationFrame(id) is called, then it’s a no-op: nothing is done.

    cancelAnimationFrame(id) makes sense in a context where you either want to stop entirely an animation loop relying on requestAnimationFrame(), from the outside, or if you want to cancel a one-shot callback, once again from the outside. From the loop itself it’s useless, if you don’t want to continue the loop, then don’t call requestAnimationFrame() again from that callback.

    Regarding your fear of overflowing the queue, this won’t happen. when you call requestAnimationFrame(callback) what it really does is to tell the browser "The next time you will pass data to the compositor, execute that right before.". If you do call requestAnimationFrame(callback) in that callback, the browser will understand it has to wait for yet the next painting frame, which if you block the engine long enough may indeed be a few monitor’s refresh ticks later, but that doesn’t matter, it will still be the browser’s next painting frame. So your loop will never queue more than one callback per painting frame, the browser will still have time to render and do its things in between, and while you will waste some monitor refreshes, and probably have a junky animation, you won’t overflow the animation frames queue.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search