Re: More on workerStart

Ok, let me throw out a crazy idea then...

partial interface Performance {
  DOMHighResTimeStamp now(optional (Window or WorkerGlobalScope)
timeOriginBasis);
};

- same behavior as previously when called without arguments - i.e. time in
ms from time origin of current context.
- optionally, when timeOriginBasis is specified, returns the time in
milliseconds from time origin of provided context.

As a result, if I get a timestamp from a worker or a different window I
can: receivedTimestamp - performance.now(sourceOfTimestamp) to translate
into current timeline?

ig

On Thu, Jun 11, 2015 at 8:56 PM, Todd Reifsteck <toddreif@microsoft.com>
wrote:

>  Agreed
>
>
>
> *From:* Ilya Grigorik [mailto:igrigorik@google.com]
> *Sent:* Wednesday, June 10, 2015 12:05 PM
> *To:* Todd Reifsteck
> *Cc:* Boris Zbarsky; Justin Rogers; Jonas Sicking; public-web-perf@w3.org;
> Przemysław Pietrzkiewicz; Travis Leithead
> *Subject:* Re: More on workerStart
>
>
>
>
>
> On Tue, Jun 9, 2015 at 10:38 PM, Todd Reifsteck <toddreif@microsoft.com>
> wrote:
>
>  We've defined the following requirements..
> * We'd like an easy way to get the workerStart within a context
> * We'd like a way to easily convert workerStart to a new timeOriginBasis
>
>
> I think we should consider expanding above requirements to a broader use
> case of "I would like to map timestamps retrieved from a worker or another
> window object into my current timeline". Doing so requires that we clearly
> define time origin's for each (in particular, dedicated vs shared workers),
> and define an API to get the offsets.
>
>
>
> ig
>