Sort of. In practice things in the "inter-frame" bucket don't all run
at the same priority in all cases and the scheduling of
requestAnimationFrame (and its relative priority wrt other things)
differs in different browsers and situations. That's off the top of my
head; there might be more complications there.
> but are there internal details
> of scheduling that would be at odds with the proposed setup in the
> second figure?
As far as I can tell, the proposed setup of the second figure _requires_
1) The set of internal priorities exactly match this figure.
2) There is a single FIFO queue per priority shown in the figure.
In particular, it completely overrides the HTML spec concept of
independently-schedulable task sources, as far as I can tell.
There's the additional complication that the HTML task sources are
specced to be order-preserving in a document-spanning way and at the
same time the new FIFO queues are defined to be order-preserving in a
limited-to-document way. There's a good chance that between those two
requirements you end up imposing a global order on pretty much
everything that shares a given event loop...
In terms of the specific question about Gecko, we are in the middle of
experimenting with and evaluating a number of possible scheduling
changes. I believe most of them are not compatible with the proposal's
FIFO-per-priority-defined-in-this-document model, because that model
seems pretty rigid in terms of what it allows in terms of the UA
prioritizing the things at "normal" priority, which is the vast majority
of what's going on, against each other.
I commented there, thank you.