Premissas: rAFnow o tempo é calculado no momento em que o conjunto de retornos de chamada é acionado. Portanto, qualquer bloqueio que ocorra antes que o primeiro retorno de chamada desse quadro seja chamado não afeta o rAFnow e é preciso - pelo menos para o primeiro retorno de chamada.

Qualquer medida de performance.now () feita antes do acionamento de um conjunto rAF deve ser anterior a rAFnow.

Teste: Registrobefore (um tempo de linha de base antesqualquer coisa acontece). Defina o próximo rAF. Compare rAFnow e atualperformance.now() parabefore para ver como eles são diferentes.

Resultados esperados:

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;
}

Observações: Quando há bloqueio antes do quadro iniciar, o rAFnow Às vezes, o tempo está incorreto, mesmo para o primeiro quadro. Às vezes, o primeiro quadronow é realmente um período anterior ao registradobefore Tempo.

Se há bloqueio acontecendo antes do quadro ou não, de vez em quando o tempo dentro do quadrorAFnow será anterior ao tempo pré-framebefore- mesmo quando eu configuro o rAFdepois de Eu faço minha primeira medição. Isso também pode acontecer sem qualquer tipo de bloqueio, embora isso seja mais raro.

(Eu recebo um erro de tempo no primeiro quadro de bloqueio na maioria das vezes. Conseguir um problema com os outros é mais raro, mas acontece ocasionalmente se você tentar executá-lo algumas vezes.)

Com testes mais extensos, constatei maus momentos com o bloqueio antes do retorno de chamada: 1% a partir de 100 quadros, sem bloqueio: 0,21645021645021645% a partir de ~ 400 quadros, aparentemente causado pela abertura de uma janela ou outra ação potencialmente intensiva da CPU pelo usuário .

Portanto, é bastante raro, mas o problema é que isso não deve acontecer. Se você quiser fazer coisas úteis com eles, simulando tempo, animação etc., precisará desses momentos para fazer sentido.

Levei em consideração o que as pessoas disseram, mas talvez ainda não esteja entendendo como as coisas funcionam. Se tudo isso for por especificação, eu adoraria algum código psuedo para solidificá-lo em minha mente.

E mais importante, se alguém tiver alguma sugestão de como eu poderia contornar esses problemas, isso seria incrível. A única coisa em que consigo pensar é tomar o meu próprioperformance.now() medir cada quadro e usá-lo - mas parece um pouco desperdício, sendo efetivamente executado duas vezes a cada quadro, além de qualquer evento acionado e assim por diante.