Re: Notification for new navigation timing entries

Forgive me for replying late in this thread but this direction is very
concerning for non-navigation uses of the timeline. Things like putting
frames in the timeline, for instance. We're loookign at huge numbers of
these callbacks, proportional to how much we want to put in the timeline.
This then means that putting things into the timeline is performance
disturbing!

Please, please please, consider the mutation observers model where a single
event is fired on the microtask unwind.

On Wed, Oct 22, 2014 at 2:49 PM, Ilya Grigorik <igrigorik@google.com> wrote:

> After some back and forth on GH, we've arrived at the following:
>
> 1) add "onentry" event handler to Performance interface
> 2) new PerformanceEntryEvent should be fired each time new event is added
> to timeline (nav+resource timing, frame timing, etc)
>     - each PEE event contains an "entry" attribute, which points to the
> source event
>
> As a hands on example, this enables:
>
>   performance.addEventListener('entry', function(event) {
>     // process event: event.entry.name, event.entry.entryType, etc...
>   });
>
> As a bonus, above behavior can be polyfilled, e.g...
>
>   var entry = performance.getEntriesByName('mark_fully_visible', 'mark');
>   var event = new PerformanceEntryEvent(entry);
>   performance.dispatchEvent(event);
>
> ----
>
> Thoughts, comments?
>
> ig
>
> On Thu, Oct 16, 2014 at 2:19 PM, Ilya Grigorik <igrigorik@google.com>
> wrote:
>
>> On Wed, Oct 15, 2014 at 7:35 AM, Eli Perelman <eperelman@mozilla.com>
>> wrote:
>>
>>> Has anything actionable come from this thread yet? I certainly find
>>> value in receiving events for performance entries and annotating them as
>>> well.
>>>
>>
>> I think we reached rough consensus that it's a good idea... and we just
>> need to draft and land the spec update.
>>
>> I've opened a tracking bug:
>> https://github.com/w3c/performance-timeline/issues/1
>>
>> ig
>>
>>
>>
>>> On Fri, Feb 28, 2014 at 3:19 PM, Joshua Peek <josh@joshpeek.com> wrote:
>>> >
>>> > For user timings, we're already using a wrapper as you mentioned.
>>> > However, I'd prefer to use the standard interface. Its also possible
>>> > for libraries outside my control to set new marks that I'd like to
>>> > report.
>>> >
>>> > New resource timing data is often outside of the user's control. New
>>> > images and scripts can be appended dynamically.
>>>
>>
>>
>