requestAnimationFrame [now] vs performance.now() time discrepancy
<p>Assumptions: rAF <code>now</code> time is calculated at the time the set of callbacks are all triggered. Therefore  any blocking that happens before the first callback of that frame is called doesn't affect the rAF <code>now</code> and it's accurate--at least for that first callback.</p>

<p>Any performance.now() measurements made before a rAF set is triggered should be earlier than rAF <code>now</code>.</p>

<p>Test: Record <code>before</code> (a baseline time before <em>anything</em> happens). Set the next rAF. Compare rAF <code>now</code> and actual <code>performance.now()</code> to <code>before</code> to see how different they are.</p>

<p>Expected results: </p>

<p><div class="snippet" data-lang="js" data-hide="false" data-console="true" data-babel="false">
<div class="snippet-code">
<pre class="snippet-code-js lang-js prettyprint-override"><code>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 -&gt; rAF now: " + (rAFnow - before));
  console.log("before frame -&gt; rAF actual: " + (actual - before));

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

// blocking
for (var i = 0, l = 0; i &lt; 10000000; i++) {
    l += i;
}</code></pre>
</div>
</div>
</p>

<p>Observations: When there is blocking before the frame starts, the rAF <code>now</code> time is at times incorrect, even for that first frame. Sometimes the first frame's <code>now</code> is actually an earlier time than the recorded <code>before</code> time.</p>

<p>Whether there is blocking happening before the frame or not, every so often the in-frame time <code>rAFnow</code> will be earlier than the pre-frame time <code>before</code>--even when I setup the rAF <em>after</em> I take my first measurement. This can also happen without any blocking whatsoever, though this is rarer.</p>

<p>(I get a timing error on the first blocking frame most of the time. Getting an issue on the others is rarer, but does happen occasionally if you try running it a few times.)</p>

<p>With more extensive testing, I've found bad times with blocking prior to callback: 1% from 100 frames, no blocking: 0.21645021645021645% from ~400 frames, seemingly caused by opening a window or some other potentially CPU-intensive action by the user.</p>

<p>So it's fairly rare, but the problem is this shouldn't happen at all. If you want to do useful things with them, simulating time, animation, etc., then you need those times to make sense.</p>

<p>I've taken into account what people have said, but maybe I am still not understanding how things work. If this is all per-spec, I'd love some psuedo-code to solidify it in my mind.</p>

<p>And more importantly, if anyone has any suggestions for how I could get around these issues, that would be awesome. The only thing I can think of is taking my own <code>performance.now()</code> measurement every frame and using that--but it seems a bit wasteful, having it effectively run twice every frame, on top of any triggered events and so on.</p>