Re: Web Smoothness

I think there are three issues around "I'd love to know layout time":

1) threads, as Boris points out, make this hard
2) which things should get timestamps reported
3) how does one get these kinds of times. "layout time since <when>"?

Working backward up there, I think reporting things "per frame"  is a good
abstraction. And, I think rAF is a great delimiter for a JS frame. Its not
the real screen frame, but rather javascript's point of view on a frame.
So, "time in layout since in the last JS frame."

Except, I wonder if instead of us tackling layout right this second, we'd
be better off starting with "how much total work was done in this frame"?
E.g. across all our various pipeline stages, how much CPU time did we use?
I think the process of figuring out that will push many of the same
threading issues in a nice general way. If we get that figured out, maybe
theres a v2 spec we can do to do stage-level timings.

On Fri, Sep 19, 2014 at 12:52 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> You just made the assumption that layout happens on the main thread.
>

We definitely need to avoid saying which threads things map to.

The reason I'm big on defining a JS-level concept of a unit of work is
because you can then number them, and then pass that number around to other
threads that are doing work, and use that to attribute off-main-thread work
to the original JS source frame. For instance, in Chrome, we use a bunch of
threads, and do raster and drawing on a mix of those threads. But, we do
keep around a number that says which rAF number a given task comes from.
This allows us to say how much CPU time was spent on a given source JS
frame.