Suposiciones: rAFnow el tiempo se calcula en el momento en que se activa el conjunto de devoluciones de llamada. Por lo tanto, cualquier bloqueo que ocurra antes de que se llame a la primera devolución de llamada de ese marco no afecta a la rAFnow y es preciso, al menos para esa primera devolución de llamada.

Cualquier medida de performance.now () realizada antes de que se active un conjunto de rAF debe ser anterior a rAFnow.

Registro de la pruebabefore (un tiempo de referencia antescualquier cosa sucede). Establezca el siguiente rAF. Comparar rAFnow y actualperformance.now() abefore para ver lo diferentes que son.

Resultados previstos:

var before = performance.now(), frames = ["with blocking", "with no blocking"], calls = 0;
requestAnimationFrame(function frame(rAFnow) {
  var actual = performance.now();
  console.log("frame " + (calls + 1) + " " + frames[calls] + ":");
  console.log("before frame -> rAF now: " + (rAFnow - before));
  console.log("before frame -> rAF actual: " + (actual - before));

  if (++calls < frames.length) { before = actual; requestAnimationFrame(frame); }
});

// blocking
for (var i = 0, l = 0; i < 10000000; i++) {
    l += i;
}

Observaciones: cuando hay un bloqueo antes de que comience el marco, el rAFnow el tiempo es a veces incorrecto, incluso para ese primer fotograma. A veces el primer fotogramanow en realidad es un tiempo anterior al registradobefore hora.

Ya sea que ocurra un bloqueo antes del marco o no, cada cierto tiempo el tiempo dentro del marcorAFnow será anterior al tiempo previo al fotogramabefore--incluso cuando configuro el rAFdespués Tomo mi primera medida. Esto también puede suceder sin ningún tipo de bloqueo, aunque esto es más raro.

(Recibo un error de sincronización en el primer fotograma de bloqueo la mayor parte del tiempo. Tener un problema en los demás es más raro, pero sucede ocasionalmente si intentas ejecutarlo varias veces).

Con pruebas más extensas, he encontrado malos momentos con el bloqueo antes de la devolución de llamada: 1% de 100 cuadros, sin bloqueo: 0.21645021645021645% de ~ 400 cuadros, aparentemente causado por la apertura de una ventana o alguna otra acción potencialmente intensiva de la CPU por parte del usuario .

Entonces es bastante raro, pero el problema es que esto no debería suceder en absoluto. Si quieres hacer cosas útiles con ellos, simulando tiempo, animación, etc., entonces necesitas esos momentos para tener sentido.

He tenido en cuenta lo que la gente ha dicho, pero tal vez todavía no entiendo cómo funcionan las cosas. Si todo esto es por especificación, me encantaría un código psuedo para solidificarlo en mi mente.

Y lo más importante, si alguien tiene alguna sugerencia sobre cómo podría solucionar estos problemas, sería increíble. Lo único en lo que puedo pensar es en tomar mi propioperformance.now() mide cada fotograma y lo usa, pero parece un poco inútil, ya que se ejecuta efectivamente dos veces cada fotograma, además de cualquier evento desencadenado, etc.