On 10/23/2014 01:28 AM, Nat Duca wrote:
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.
MutationObserver doesn't use any events.
Just a sequence of MutationRecords which are passed to the callback.
What is the reason why navigation timing entries notification should use
microtasks and not tasks? Or actually, maybe it should
use animation frame ticks?
-Olli
On Wed, Oct 22, 2014 at 2:49 PM, Ilya Grigorik <igrigo...@google.com
<mailto:igrigo...@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 <http://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 <igrigo...@google.com
<mailto:igrigo...@google.com>> wrote:
On Wed, Oct 15, 2014 at 7:35 AM, Eli Perelman <eperel...@mozilla.com
<mailto:eperel...@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 <j...@joshpeek.com
<mailto:j...@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.
