Re: Web Smoothness

This would be fantastic. One quick comment -- it'd be great if there was
some kind of breakdown of the time spent on the main thread (JS execution
vs layout -- basically, exactly what Chrome Developer Tools shows in the
timeline view).

On Fri, Sep 19, 2014 at 4:24 AM, Michael Blain <mpb@google.com> wrote:

> Hi all,
>
> Some Chrome folk and I are interested in monitoring the smoothness of web
> pages in the wild. Rendering smoothness is hard to measure with polyfill
> today because most browsers do off-main-thread animations and scrolling.
> Here are some examples of content for which we'd like to get accurate
> rendering smoothness information:
>
>
>    -
>
>    CSS animation with jank checkbox:
>    -
>
>       [
>       https://github.com/GoogleChrome/websmoothness/blob/master/examples/css_anim.html
>       ]
>
>
>    -
>
>       What we want to measure here is FPS of the animation :)
>       -
>
>    Two coordinated animation strategies - CSS and RAF:
>    -
>
>       [
>       https://github.com/GoogleChrome/websmoothness/blob/master/examples/coordinated_anim.html
>       ]
>       -
>
>       What we want to measure here is FPS of the animations :)
>       -
>
>       If the browser is lightly loaded, these two animations should be in
>       sync.
>       -
>
>    Scrollable page with jank checkbox:
>    -
>
>       [
>       https://github.com/GoogleChrome/websmoothness/blob/master/examples/scroll.html
>       ]
>       -
>
>       What we want to measure here is smoothness when a user scrolls :)
>       -
>
>    Click button with a very long time to first frame:
>    -
>
>       [
>       https://github.com/GoogleChrome/websmoothness/blob/master/examples/time_to_first_frame.html
>       ]
>       -
>
>       What we want to measure here is time to first frame.
>       -
>
>       RAF gets us AN answer, but not necessarily the most accurate one.
>
>
> We've found that its very hard to agree on a definition of smoothness
> without knowing a lot about the context and the intent of the web
> developer. By recording events when frames are committed on the main thread
> to the compositor, and then later when they are drawn by the compositor to
> the screen, we don’t have to assume what the developer is intending.
> Instead, we can record the raw data into a timeline, and then let the
> ecosystem create javascript libraries on top that refine the data into
> domain-specific metrics.
> Our initial thought was that the performance timeline would be a great
> place for such information [http://www.w3.org/TR/performance-timeline/
> <http://www.w3.org/TR/performance-timeline/#sec-PerformanceEntry-interface>
> ].
> window.performance.getEntries() returns the ‘mark’ and ‘resource’ timing
> events currently collected by the browser. We could add a
> PerformanceSmoothnessEntry that records each time the compositor updates
> the screen or the main frame sends a change to the compositor. What do
> folks think? Anyone interested in helping us move this forward?
> Thanks!
> Michael Blain
> mpb@google..com <mpb@google.com>
>