Re: [Paint Performance] - Exposing paint rects to the DOM

What are the use cases?

- James


On Tue, Aug 13, 2013 at 10:14 AM, Patrick Meenan <pmeenan@webpagetest.org>wrote:

>  I'm working on exposing Chrome's paint events to the DOM so that sites
> can report visual metrics back as part of their RUM.  I know there is a lot
> of controversy around paint events but it would be great if we could at
> least define how they could be exposed should a browser vendor decide to
> expose them.
>
> I can write up a full proposal in the formal template but I wanted to
> throw out a straw-man that basically mimics the behavior of the resource
> timing interface.
>
> - The paint events will consist of a rectangle (left, top, width, height)
> and a DOMHighResTimeStamp relative to the start of navigation
>
> - The array of events would be fetched through
> window.performance.getPaintEvents()
>
> - The number of events to be tracked can be set by
> window.performance.setPaintEventsBufferSize(#of events) and defaults to
> something reasonable given the events are quite small (actual numbers TBD
> but 1500 as an initial default would not be unreasonable)
>
> - The accumulated paint events can be cleared by calling
> window.performance.clearPaintEvents()
>
> - An event (onpainteventsbufferfull) will fire when the buffer is full
> (TBD, should this be a rolling window and always drop from the head instead
> of failing to insert?)
>
> - The paint events will be bound to the document that they belong to
> (paint events for frames are tied to that specific frame).  Otherwise there
> will be all sorts of opportunity for privacy leakage (embedding an iFrame
> to a bank page and watching where it paints for example).
>
> *A couple of other nice-to-have's:*
> - Standardize a firstPaint attribute on the Navigation Timing interface
> - Standardize a bodyStarted attribute on the Navigation Timing interface
> (technically easy to capture in js anyway but I'm planning on filtering out
> all of the bogus paint events before the browser hits the body and thought
> it might be useful for RUM to get for free)
> - Provide an interface for helper calculations (I'm planning for a simple
> way to get SpeedIndex without everyone having to implement the algorithm
> against the raw paint rects for example)
>
> I know that browsers can't necessarily expose the exact time when pixels
> hit the screen because they pay offload a lot of that to hardware but the
> plan is to get as close to that as possible.  In the case of Chrome there
> could be a difference of 10's to 100's of ms between when blink passes a
> rect off to be rendered and when it hits the screen but the information
> available from blink is still worth exposing (and matches what you get in
> the dev tools when you show paint rects and in the timeline).
>
> Thanks,
>
> -Pat
>