Re: Firefox and User Timing API in workers

Boris, Jonas, thanks.. owe you a reply on both of those once this I/O thing
has blown over :)

In the meantime, would either of you guys be able to join next week's conf
call -- Jun 3rd, 12PM PST? In addition to what we're discussing in this
thread, I'd love to hear your thoughts and feedback on FT + :visited [1],
and attribute filtering [2].

[1] https://github.com/w3c/frame-timing/issues/40
[2] https://github.com/w3c/performance-timeline/pull/11

On Thu, May 28, 2015 at 3:33 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, May 27, 2015 at 5:56 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> > On 5/27/15 6:01 PM, Ilya Grigorik wrote:
> >>
> >> That's what I meant to say.. Single attribute that works across all
> >> worker cases :)
> >
> > And I'm saying I'd prefer a single attribute that works across all
> globals
> > period and represents the zero time of the monotonic clock in that
> global,
> > so people don't have to branch their code on whether they're in a worker
> or
> > not.
>
> Note that for dedicated Workers there are two reasonable "zero times".
>
> A dedicated Worker is essentially an extra thread allowing you to do
> heavy work from a webpage. So many times it likely is useful to
> measure the "zero time" inside a dedicated worker as the same as the
> "zero time" of the page that instantiated the worker.
>
> Consider for example a webpage that lazily spins up one or more
> workers and hands work items to whichever worker is available to
> process the given task. In this case the start time of the worker is
> irrelevant and what you want to track is when a task happens in
> relation to page start.
>
> In short, dedicated workers are often just like a JS library that's
> running in a page. It just happens that the library runs on a separate
> OS thread in order to not disrupt UI.
>
> Other times a dedicated worker might perform work as part of the
> processing that it does when the worker first loads. Here it might be
> more interesting to measure time against when the worker started to
> load, rather than when the page that created the worker started to
> load.
>
> Shared Workers and Service Workers seem more like normal pages and
> what you're generally interested in is measuring time compared to when
> the worker started to load rather than when an individual page started
> to load.
>
> Also note that in spec Shared Workers (and I hope Service Workers) can
> create dedicated workers. In which case the dedicated worker is a
> workhorse for the shared/service worker and so measuring time against
> the parent worker is what's interesting.
>
>
> But I generally agree with Boris that having properties (and APIs in
> general) that work across all globals are preferable than just
> creating consistency for the various types of workers that exist.
>
> I'm just arguing that we might need to have two properties rather than
> one here. But I see no reason we couldn't make those two exist in all
> globals.
>
> / Jonas
>
>