timestamp of requestAnimationFrame is not reliable

Question

I think the timestamp argument passed by requestAnimationFrame is computed wrongly (tested in Chrome and Firefox).

In the snippet below, I have a loop which takes approx. 300ms (you may have to tweak the number of loop iterations). The calculated delta should always be larger than the printed 'duration' of the loop. The weird thing is, sometimes it is slower sometimes not. Why?

let timeElapsed = 0;
let animationID;


const loop = timestamp => {
  const delta = timestamp - timeElapsed;
  timeElapsed = timestamp;

  console.log('delta', delta);
  
  // some heavy load for the frame
  const start = performance.now();
  let sum = 0;
  for (let i = 0; i < 10000000; i++) {
    sum += i ** i;
  }
  console.warn('duration', performance.now() - start);

  animationID = requestAnimationFrame(loop)
}

animationID = requestAnimationFrame(loop);

setTimeout(() => {
    cancelAnimationFrame(animationID);
}, 2000);

jsFiddle: https://jsfiddle.net/Kritten/ohd1ysmg/53/

Please not that the snippet stops after two second.

Answer 1

At least in Blink and Gecko, the timestamp passed to rAF callback is the one of the last VSync pulse.

In the snippet, the CPU and the event-loop are locked for about 300ms, but the monitor still does emit its VSync pulse at the same rate, in parallel.

When the browser is done doing this 300ms computation, it has to schedule a new animation frame.
At the next event-loop iteration it will check if the monitor has sent a new VSync pulse and since it did (about 18 times on a 60Hz), it will execute the new rAF callbacks almost instantly.

The timestamp passed to rAF callback may thus indeed be the one of a time prior to when your last callback ended, because the event-loop got freed after the last VSync pulse.

One way to force this is to make your computation last just a bit more than a frame's duration, for instance on a 60Hz monitor VSync pulses will happen every 16.67ms, so if we lock the event-loop for 16.7ms we are quite sure to have a timestamp delta lesser than the actual computation time:

let stopped = false;
let perf_elapsed = performance.now();
let timestamp_elapsed = 0;
let computation_time = 0;
let raf_id;

const loop = timestamp => {

  const perf_now = performance.now();

  const timestamp_delta = +(timestamp - timestamp_elapsed).toFixed(2);
  timestamp_elapsed = timestamp;

  const perf_delta = +(perf_now - perf_elapsed).toFixed(2);
  perf_elapsed = perf_now;

  const ERROR = timestamp_delta < computation_time;
  if (computation_time) {
    console.log({
      computation_time,
      timestamp_delta,
      perf_delta,
      ERROR
    });
  }

  // some heavy load for the frame
  const computation_start = performance.now();
  const frame_duration = 1000 / frequency.value;
  const computation_duration = (Math.ceil(frame_duration * 10) + 1) / 10; // add 0.1 ms 
  while (performance.now() - computation_start < computation_duration) {}
  computation_time = performance.now() - computation_start;

  
  raf_id = requestAnimationFrame(loop)
  
}

frequency.oninput = evt => {
  cancelAnimationFrame( raf_id );
  console.clear();
  raf_id = requestAnimationFrame(loop);
  setTimeout(() => {
    cancelAnimationFrame( raf_id );
  }, 2000);
};
frequency.oninput();

In case your monitor has a different frame-rate than th common 60Hz, you can insert it here:

<input type="number" id="frequency" value="60" steps="0.1">

So what to use between this timestamp and performance.now() is your call I guess, the timestamp tells you when the frame began, performance.now() will tell you when your code executes, you could use both if needed. Even without such a big computation spanning over frames, you can very well have an other task scheduled before yours that took a few ms to complete or even a big CSS composition that should get performed after, and you have no real way to know.