-
Notifications
You must be signed in to change notification settings - Fork 361
Description
Opening this as a new issue because I don't want to derail #506. cc @magcius
Originally posted by @litherum in #506 (comment)
So there is a microtask queue drain between the
rAF()callback and the present.
Last I checked, Chromium actually implements this the other way (i.e. incorrectly; I'm assuming your reading of the spec is correct). It does not drain the microtask queue between the rAF callback and the present.
I was deep in an email conversation on this topic several months ago with @AshleyScirra, which I irresponsibly dropped the ball on and haven't replied (sorry, Ash!). Ash, evidently per spec (sorry I didn't check before), your desired behavior is actually the correct one, and Chromium is buggy.
That said... I'm actually very skeptical that the current spec text is how it ought to be. Take some rAF callback like this:
async function frame() {
requestAnimationFrame(frame);
drawScene();
await updateHUDState();
drawHUD();
}
requestAnimationFrame(frame);- If you take the spec way, then whether your HUD renders in the correct frame or not depends on whether the promise resolves as a task or as a microtask. While this behavior is very much present and observable in JS today, it almost never makes a difference in correctness except in quite arcane cases, which allows the majority of developers to never think about tasks vs microtasks.
- If you take the Chromium way, then your HUD never renders. This can be annoying to code around, but at least it means you never flakily present in the middle of drawing - the behavior is consistent and you know you have to fix it.