[Paint Performance] - Exposing paint rects to the DOM

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