Re: Provide capability in user timing API to mark for user agent events

I'm pretty sure you can use frame timing plus user timing to get what you
want:
1. you requestAnimationFrame. Record the timestamp of the frame.
2. create a performance observer that looks for main frame records. Wait
for the main frame record whose frame timestamp matches your rAF timestamp.
3. create a performance observer that looks for the drawn record with the
frame number for the main frame record.

If you read the source for this, you may find the details:
https://github.com/GoogleChrome/frame-timing-polyfill/blob/master/examples/time_to_first_frame.html

Especially:
https://github.com/GoogleChrome/frame-timing-polyfill/blob/master/bin/web_smoothness.js#L766

Though, I think this polyfill is a bit out of date given the latest spec
changes.

It may be that we want a public method for requestFirstFramePromise that
does these steps above, so its more obvious to people that frame timing can
do this. I agree its very non obvious. :)

On Thu, Mar 12, 2015 at 12:01 PM, Chih-Kai (Patrick) Wang <i@ckwang.info>
wrote:

> On 3/12/15 2:29 AM, Philippe Le Hegaret wrote:
> > On 03/11/2015 06:04 AM, Chih-Kai (Patrick) Wang wrote:
> >> Hi all,
> >>
> >> I am thinking of adding an API in navigator.performance to "ask
> >> browser to mark when something happens". Currently, user timing API
> >> provides us with methods to mark in web apps. However, to get more
> >> accurate mark of specific event, we may need supports from user agent.
> >> For example, we might care about when is the DOM modification we made in
> >> Javascript drawn onto screen. Calling to performance.mark() in the
> >> script is not able to mark when the composition happens. Another way is
> >> to listen to specific event of the operation, but the event itself takes
> >> time to propagate to content. For instance, under current multi-process
> >> architecture Firefox OS, the MozAfterPaint event in content process can
> >> be fired in up to 80ms after the corresponding composition done in
> >> parent process.
> >>
> >> The API I'd like to expose might look like:
> >>
> >>    performance.delayedMark('composite', 'done-visually-update');
> >>
> >> which means "set a 'done-visually-update' mark when next composition
> >> happens".
> >>
> >> Do you have any thought or comment?
> >>
> > My understanding is that the ability to figure out a DOM modification is
> > actually being displayed on the screen is tricky and varies greatly
> > between the browser engines. Did you look into Frame Timing?
> >  http://w3c.github.io/frame-timing/
>
> Frame timing API enables us to log the compositions, but my
> understanding to frame timing API is that it provides a series of marks
> for each composition, so we can't get the timing data of when a specific
> event happens. Like we might be interested in when is something be drawn
> onto the screen, instead of an average of fps in a specific period.
>
> Patrick
>
>