Re: [frame-timing] Processing model proposal

> I'm not sure why rAF callbacks are run after rendering here? In Gecko, at
least, we do them before
> style/layout/drawing[1] and the HTML spec has the same[2].

rAF isn't run after rendering, if this write-up suggests that, it shouldn't
be changed.

As far as Step 3, the mental model I'm working from is multi-threaded, but
not significantly so.
1. There is a "begin" point to a frame. Could be a timer, a rAF, an input
handler, etc.
2. There is an "end of processing" for a frame. Could be a thread which
collects all the async jobs when they finish, could be a timer which
collects all work which made a particular deadline. Could have just been
single-threaded and reached the end of work.
3. There is a hand-off of rendered work to a compositor thread/system.

This write-up is intending to say: "When all the computation to handle the
changes for this frame are done, use the next rAF start time as an
endpoint". It's trying to get away from assigning meaning to the exact time
work was done, since that doesn't actually give any info about the workload
or spare capacity for future frames. we think it's more useful (right now)
to say a more binary "you hit your deadline" or "you missed your deadline,
and are janking."

Is this model too narrow/limiting, or is it just not worded as clearly as
it could be?

Thanks,
-Mike


On Mon, Mar 23, 2015 at 9:01 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 3/20/15 3:59 PM, Michael Blain wrote:
>
>> Hi Web Perf,
>> Here's what we have currently. Would love to hear thoughts/comments?
>>
>> https://docs.google.com/document/d/1Li_R8v4po9QwjLxNrrD0CCfgYqk4wWA1G
>> e6pX4jokfQ/edit?usp=sharing
>>
>> This would go in a new section of http://w3c.github.io/frame-timing/
>>
>
> I'd like to understand exactly what step 3 means here and what it's really
> assuming about what a "frame" is.
>
> For example, image decoding is an async operation running on a different
> thread from JS execution.  So is layout, conceptually (and in practice in
> servo).  So is rasterization.
>
> So for example, you could have layout start due to DOM modification from a
> timer, and more timers fire while that layout pass is still running. It's
> possible to have multiple presents to screen while that layout pass is
> running, for that matter.
>
> In general, it seems to me like there's a mental model here of what a
> "frame" is that doesn't match all current UAs, much less future UAs, and it
> would be a good idea to clearly write down what that mental model is, so we
> can reason about it and adjust it as needed so that it does not
> overconstrain UA implementations and reflects reality in all UAs.
>
> -Boris
>
>