Re: [HighResTime] Web Worker support

Definitely on board for this.

originTime might not be the best name, because "origin" already has meaning
on the web. Maybe monotonicClockOffset?

I'm fine with browser start time or something similar for the reference.
Maybe we even just leave it undefined with a suggestion that implementers
pick something like startup time. I'd hate to have to define "browser
startup." We should just specify it needs to be a fixed point for the
entire browsing session.

James


On Wed, Sep 11, 2013 at 11:45 AM, Jatinder Mann <jmann@microsoft.com> wrote:

>  We were thinking about introducing a performance.originTime, which would
> define the time value from which performance.now() is measured. For a
> dedicated worker or a document the origin time is the start of page
> navigation of that document, and for a shared worker the origin time is
> when the shared worker is created. The originTime attribute would describe
> that origin time relative to a reference point in time before the start of
> navigation of the document, e.g., unix epoch or start of browser launch.**
> **
>
> ** **
>
> Suppose I have a shared worker A that was created 10ms after the start of
> navigation of the parent document. If I call performance.now() 5ms after
> the shared worker A was created in both the worker and the parent context,
> I should see the following values:****
>
> ** **
>
> Shared worker A:****
>
> performance.now(): 5.000 ms****
>
> ** **
>
> Parent context:****
>
> performance.now(): 15.000 ms****
>
> ** **
>
> ** **
>
> If we introduce a performance.originTime that describes the time relative
> to unix epoch, I may get something like so:****
>
> ** **
>
> Shared worker A:****
>
> performance.now(): 5.000 ms****
>
> performance.originTime: 1378924562563.000 ms****
>
> performance.originTime + performance.now(): 1378924562568.000 ms****
>
> ** **
>
> Parent context:****
>
> performance.now(): 15.000 ms****
>
> performance.originTime: 1378924562553.000 ms****
>
> performance.originTime + performance.now(): 1378924562568.000 ms****
>
> ** **
>
> Adding originTime to the performance.now(), gives you a time value that is
> comparable in either context. This assumes that we have enough bits in a
> double to describe time since Jan 01 1970 in milliseconds in microsecond
> resolution. ** **
>
> ** **
>
> Alternatively, we can define the origin for originTime to be the launch of
> the browser. Assuming the parent context was created 100ms after the launch
> of the browser, we would get something like so:****
>
> ** **
>
> Shared worker A:****
>
> performance.now(): 5.000 ms****
>
> performance.originTime: 110.000 ms****
>
> performance.originTime + performance.now(): 115.000 ms****
>
> ** **
>
> Parent context:****
>
> performance.now(): 15.000 ms****
>
> performance.originTime: 100.000 ms****
>
> performance.originTime + performance.now(): 115.000 ms****
>
> ** **
>
> Not using unix epoch has the benefit that developers won’t mistakenly
> compare this time with Date.now(), which isn’t monotonically increasing and
> can be changed. ****
>
> ** **
>
> Any thoughts on this approach?****
>
> ** **
>
> Jatinder****
>
> ** **
>
> *From:* Ben Vanik [mailto:benvanik@google.com]
> *Sent:* Tuesday, September 10, 2013 8:59 PM
> *To:* Jatinder Mann
> *Cc:* James Simonsen; public-web-perf
>
> *Subject:* Re: [HighResTime] Web Worker support****
>
> ** **
>
> Our use cases require comparing times from workers with their parent page
> context, but if that's possible to do with a delta of load time of the
> different contexts (performance.timing.navigationStart in the page and
> performance.whatever in the worker) instead of having now() values line up
> that's fine.****
>
> ** **
>
> On Tue, Sep 10, 2013 at 4:09 PM, Jatinder Mann <jmann@microsoft.com>
> wrote:****
>
>  Let’s discuss performance.originTime in this week’s call. We had raised
> the idea of possibly defining the origin time, so that time values obtained
> from a shared worker context could be compared with a dedicated worker or
> the top level browsing context. Not sure how common it will be to compare
> time values from different contexts, but it’s worth discussing.****
>
>  ****
>
> Thanks,****
>
> Jatinder****
>
>  ****
>
> *From:* James Simonsen [mailto:simonjam@chromium.org]
> *Sent:* Wednesday, September 4, 2013 1:35 PM
> *To:* public-web-perf****
>
>
> *Subject:* Re: [HighResTime] Web Worker support****
>
>  ****
>
> On Tue, May 14, 2013 at 11:20 AM, James Simonsen <simonjam@chromium.org>
> wrote:****
>
>  Sorry for being late getting back to this thread...****
>
>  ****
>
> On Thu, Apr 18, 2013 at 10:44 AM, Jatinder Mann <jmann@microsoft.com>
> wrote:****
>
>  Ben,****
>
>  ****
>
> If you’re just looking at deltas, differences between two time values, the
> origin shouldn’t matter. Is there a case where deltas wouldn’t be good
> enough and you would want the absolute numbers?****
>
>  ****
>
> If we were are to provide the origin time as a separate value (e.g.,
> performance.originTime), it would need to be in the same sub-millisecond
> resolution in order to be comparable with other DOMHighResTimeStamps; the
> spec currently suggests one thousandth of a millisecond. Double precision
> may be able to support that for milliseconds since Unix epoch.****
>
>   ****
>
> I don't fully understand the originTime. Is this effectively a global
> monotonic clock across all processes (workers and tabs)?****
>
>   ****
>
> Ping? Are we going to do anything about this?****
>
>  ****
>
> James ****
>
>  ** **
>