Re: Notification for new navigation timing entries

On Mon, Dec 8, 2014 at 5:14 PM, Nat Duca <nduca@google.com> wrote:

> Correct me if I'm wrong, ilya, but the reason I think we were looking at
> specifying when events are inserted in the timeline was because there were
> no callbacks when events were actually inserted. This made it hard for JS
> to "await" a navigation event.
>

Yep, exactly. We don't have a notification mechanism for new perf events,
which means that applications need to poll the buffers (ugh), and run the
risk of trampling on each other (e.g. someone clears the buffer, causing
everyone else to miss events).

In PerformanceObserver, you would make an observer for nav events, listen
> to its callback and then disconnect when they arrived. In that model, its
> up to the browser when to deliver those callbacks, which lets us defer
> their delivery as long as we think is necessary to get good performance.
> That's much better for performance.
>

Nav events in particular are probably not the best example, but otherwise
yes that's exactly the model - e.g. listen for one of "mark", "measure",
"resource", or "render" perf events and run relevant processing.


> Ilya: to your point, having observers always get notifications sounds
> great. But, if so, I wonder if we can figure out how we can specify things
> like frame-timing events to never add to the buffer in the first place.
> Since they have nonzero overhead to collect, we'd be avoiding a footgun if
> they're only obtainable via observers.
>

I've entertained the same thought.. if we have observers, do we need the
buffer at all? And I think the answer might still be yes: what if I want to
get frame-timing events for the initialization sequence of the page, prior
to my app registering an observer? E.g. get timing events for first
frame(s)? Does that mean I must register my observer as very first thing on
my page, and will that give me what I'm after?

ig