Intent to implement and ship: Performance.translateTime

[Boris Zbarsky]

Summary: A new method on Performance that allows translating a timestamp
from one timeline to another. The idea is that you can take a
performance.now() value or performance mark from some other global and
convert them to the timeline of your global. It works like this:

var myTime = Performance.translateTime(otherTime, otherGlobal);

where otherGlobal is a Window, Worker, SharedWorker, or ServiceWorker.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1169068

Spec: http://w3c.github.io/hr-time/

Target release: 45

State in other UAs: Chrome plans to implement, unclear on the others.

-Boris

P.S. I'm not doing the impl work, just the paperwork.

[Jonas Sicking]

This API doesn't seem to work for nested workers (which Blink doesn't
implement), does it? Since there's no way in the window to get hold of
a reference of a sub-sub-worker.

It also doesn't seem possible for a worker to convert to the timeline
of a parent window, since there's no object representing the parent of
a worker.

/ Jonas

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Boris Zbarsky]

On 11/19/15 5:39 PM, Jonas Sicking wrote:
> This API doesn't seem to work for nested workers (which Blink doesn't
> implement), does it? Since there's no way in the window to get hold of
> a reference of a sub-sub-worker.

While true, there is also no way to directly get a message from a
sub-sub-worker, right? The only way to get one is via the intermediate
worker.

So you have a window create worker W1, W1 creates W2. W2 does
something, posts a message back to W1 with some timestamps. W1
translates those into its timeline and posts message back to the window,
which translates into its timeline.

> It also doesn't seem possible for a worker to convert to the timeline
> of a parent window, since there's no object representing the parent of
> a worker.

That's true. If you want to ship timestamps from a window to a worker,
there's no convenient way to do that, though you can hack it together
like so:


w.postMessage(myTimeStamp - Performance.translateTime(0, w))

It seemed to me when this was being discussed that typically your
timestamps would flow the other way, but maybe that's a bad assumption?

-Boris

[Jonas Sicking]

On Thu, Nov 19, 2015 at 2:48 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> On 11/19/15 5:39 PM, Jonas Sicking wrote:
>>
>> This API doesn't seem to work for nested workers (which Blink doesn't
>> implement), does it? Since there's no way in the window to get hold of
>> a reference of a sub-sub-worker.
>
> While true, there is also no way to directly get a message from a
> sub-sub-worker, right? The only way to get one is via the intermediate
> worker.

You can actually create a MessageChannel and then send one of the
ports to a sub-sub-worker.

Unfortunately the other port can't be used as something that
represents the sub-sub-worker since even after a port has started
getting used, it can be sent around again.

> So you have a window create worker W1, W1 creates W2. W2 does something,
> posts a message back to W1 with some timestamps. W1 translates those into
> its timeline and posts message back to the window, which translates into its
> timeline.

Yes, this is possible. It's not great, but it's probably a fine enough solution.

>> It also doesn't seem possible for a worker to convert to the timeline
>> of a parent window, since there's no object representing the parent of
>> a worker.
>
> That's true. If you want to ship timestamps from a window to a worker,
> there's no convenient way to do that, though you can hack it together like
> so:
>
> w.postMessage(myTimeStamp - Performance.translateTime(0, w))
>
> It seemed to me when this was being discussed that typically your timestamps
> would flow the other way, but maybe that's a bad assumption?

I suspect having a worker which takes care of coordinating network
traffic to a server is likely to be a good design. Especially having a
sharedworker or serviceworker take care of coordinating the network
traffic if the website expects the user to have multiple tabs open.

Though Service Workers do actually have a 'client' object which
represent window objects. So we could enable passing those as global
to the translate function.

/ Jonas

[Boris Zbarsky]

On 11/19/15 6:57 PM, Jonas Sicking wrote:
> You can actually create a MessageChannel and then send one of the
> ports to a sub-sub-worker.

Ah, good point.

> Unfortunately the other port can't be used as something that
> represents the sub-sub-worker since even after a port has started
> getting used, it can be sent around again.

Right. There's really no good solution here short of introducing
something that represents an arbitrary worker to an arbitrary window or
worker, right? That's unfortunate...

> Though Service Workers do actually have a 'client' object which
> represent window objects. So we could enable passing those as global
> to the translate function.

That's a good idea. Want to raise it with the webperf WG? Seems like
it wouldn't be that hard to implement.

-Boris

[Jonas Sicking]

On Thu, Nov 19, 2015 at 5:38 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
>> Though Service Workers do actually have a 'client' object which
>> represent window objects. So we could enable passing those as global
>> to the translate function.
>
> That's a good idea. Want to raise it with the webperf WG? Seems like it
> wouldn't be that hard to implement.

I'd be quite happy if someone else would :)

/ Jonas

[Anne van Kesteren]

On Fri, Nov 20, 2015 at 9:49 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> I'd be quite happy if someone else would :)

Filed https://github.com/w3c/hr-time/issues/22 on the general nested
worker problem. Filed https://github.com/w3c/hr-time/issues/23 on the
Client object thing.


--
https://annevankesteren.nl/