Do we need to call cancelAnimationFrame for frames prior to the current requestAnimationFrame?

Question

I have been working with animation and studying and reading a lot I found this method with the best performance among others existing, both for use on the computer and for Smartphones, abusurdamente efficient.

My doubt is whether this correct call cancelAnimationFrame to the previous frame if you are delayed or not necessary to put this cancellation line and why?

Explaining the logic:

/* CRYO VARIABLE

Raf: int, old/current Raf id value running */

/* CRYO VARIABLE

time: float, stores the Domhighrestimestamp value that is timed with each run Raf, floating values can represent microseconds/miileseconds depending on the browser, this value must be used with the current time for scorpo comparisons and execution time */

/* Function: fc_loop_infinite_raf (Arg) Description: Creation: 20/1/2019 Updated: 3/3/2019

https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame

requestAnimationFrame: function, method informs the browser that Voce wants to run an animation and prompts the browser to call a specified function to update an animation before the next repeat. The method receives a call return as an argument to be called before the repinture.

Arg: from "Function fc_loop_infinito_raf (Arg), and now a Domhighrestimestamp provided by Raf

https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp

logic and practice withdrawal of:

https://developer.mozilla.org/en-US/docs/Games/Anatomy */

;{

  let

  raf = 0,

  tempo = 0,

  fc_loop_infinito_raf = function (arg) {

    // CONDICAO CANCELA OS FRAMES ANTIGOS
    if (arg > tempo) {

      console.log ('CANCELO RAF '+ raf);

      // CANCELA O FRAME ANTERIOR CASO TENHA OCORRIDO ATRASO
      window.cancelAnimationFrame (raf);

    }

    raf = window.requestAnimationFrame (fc_loop_infinito_raf);

    tempo = (arg !== undefined ? arg : 0);

    // FUNCAO DE ATUALIZACAO

    // FUNCAO DESENHA

    console.log ('EXECUTA RAF '+ raf +' - '+ tempo);

  };

  // INICIO CICLO DO RAF
  fc_loop_infinito_raf ();

}

or so would be correct? (If so, why?)

   ;{

      let

      raf = 0,

      tempo = 0,

      fc_loop_infinito_raf = function (arg) {

        raf = window.requestAnimationFrame (fc_loop_infinito_raf);

        tempo = (arg !== undefined ? arg : 0);

        // FUNCAO DE ATUALIZACAO

        // FUNCAO DESENHA

        console.log ('EXECUTA RAF '+ raf +' - '+ tempo);

      };

      // INICIO CICLO DO RAF
      fc_loop_infinito_raf ();

    }

There is this similar question in the English stack but no answer!

https://stackoverflow.com/questions/52508261/do-we-need-to-clear-a-timeout-when-using-requestanimationframe-polyfill

Answer 1

First you need to understand what your second example, the simplest, does, then you’ll understand that the first example doesn’t make sense. After reading my answer, I suggest you reread the article you linked to on MDN, in its entirety. If the problem is English, you have a portuguese version also.

When you call requestAnimationFrame and passes a callback, you are asking the browser to run this callback just before the next operation of repaint, which is when he (re)draws the contents of the page on the screen. The execution of the callback is an asynchronous operation; it does not occur at the time of the call of requestAnimationFrame, yes later (at the "breathtaking" of the browser).

Each callback call corresponds to a single frame of the animation, the "current frame". And the callback itself schedules the next callback call - "next frame" processing - calling again requestAnimationFrame and passing to himself. If the "current frame" is who schedules the execution of the "next frame", it is logical consequence the "current frame" was only processed because it was scheduled during the processing of the "previous frame".

Now let’s see what you asked:

My question is whether it’s right to call cancelAnimationFrame for the previous frame if delayed, or [if] not required (...)

Do you realize this doesn’t make sense? At the time you want to call cancelAnimationFrame, is already too late, the "previous frame" - more precisely, the previous execution of your callback - is over, you have no way to cancel anything else. The cancelAnimationFrame does not serve to solve performance issues, serves to interrupt the animation loop, disallowing the next scheduled execution.

I understand you’re exploring performance solutions. The problem is that there is no single, abstract answer, "this way is always better and ready". It depends on what you are doing, more precisely on what is done in the parts of your code that calculate the state of the animation, and the ones that properly draw the frame. The article you linked shows some ways to deal with it - and none of them uses cancelAnimationFrame.