- From: Ilya Grigorik <igrigorik@google.com>
- Date: Fri, 1 May 2015 11:26:22 -0700
- To: Michael Blain <mpb@chromium.org>
- Cc: Todd Reifsteck <toddreif@microsoft.com>, James Robinson <jamesr@chromium.org>, public-web-perf <public-web-perf@w3.org>
- Message-ID: <CADXXVKpwxj7Hspm8N64PonYKhQrRvpiJXzdLNWaKzaJUCQ-qaQ@mail.gmail.com>
Hmm. I think we may need to tweak the language a bit.. but I think the general shape ("write a new PerformanceRenderTiming event to the Performance timeline") is right. FWIW, we landed the basic definition of PerfObserver in Performance Timeline, and I think the next step is to add a processing section that explicitly talks about when events are created and then delivered into appropriate buffers + observers. Once we have that, we'll have a hook that other specs can use to register events with the Performance Timeline... At least, that's how I'm picturing it at the moment. There is only the minor detail of writing it down.. :) ig On Wed, Apr 29, 2015 at 2:23 PM, Michael Blain <mpb@chromium.org> wrote: > I am not opposed to that change... > What's a better way to specify it? > Just that the events get generated and leave where they go as an exercise > for the reader? > Thanks, > -Mike > > On Wed, Apr 29, 2015 at 1:56 PM, Todd Reifsteck <toddreif@microsoft.com> > wrote: > >> It may make sense to remove the part about the event going to the >> performance timeline and leave that to definition by frame timing spec >> rather than pushing that bit into HTML spec. Previous discussions have >> leaned towards only exposing frame timing on Performance Observer. >> >> >> >> Ilya/Michael, what do you think? >> >> >> >> -Todd >> >> >> >> *From:* jamesr@google.com [mailto:jamesr@google.com] *On Behalf Of *James >> Robinson >> *Sent:* Monday, April 13, 2015 4:31 PM >> *To:* Michael Blain >> *Cc:* public-web-perf >> *Subject:* Re: [frame-timing] Processing model proposal >> >> >> >> Great, thanks for following up on that. >> >> >> >> On Mon, Apr 13, 2015 at 2:57 PM, Michael Blain <mpb@chromium.org> wrote: >> >> I heard back from Hixie on >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=28347 >> It all sounds fine to WHATWG. If there is another browser vendor >> (non-Chrome) who wants to chime in with a +1 they'll go ahead and make the >> edits. >> >> Thanks, >> -Mike >> >> >> >> On Thu, Mar 26, 2015 at 11:51 AM, Michael Blain <mpb@google.com> wrote: >> >> Opened https://www.w3.org/Bugs/Public/show_bug.cgi?id=28347 >> >> Thanks, >> -Mike >> >> >> >> On Wed, Mar 25, 2015 at 11:24 PM, Anne van Kesteren <annevk@annevk.nl> >> wrote: >> >> On Wed, Mar 25, 2015 at 11:52 PM, Michael Blain <mpb@chromium.org> wrote: >> > In a similar vein, this model doesn't seem to specify an event >> processing >> > loop for compositing. I think we should keep that part in the >> Frame-Timing >> > doc for the moment, but reach out to WHATWG and see if it makes sense >> to >> > add another loop type to this model. >> >> Reaching out seems like a good idea. Filing a bug is probably a good >> course of action. >> >> >> > Thoughts? Comments? >> >> Monkey patching the event loop model seems like a bad idea. Though >> that has not stopped people from doing it before. >> >> >> -- >> https://annevankesteren.nl/ >> >> >> >> >> >> >> > >
Received on Friday, 1 May 2015 18:27:30 UTC