Re: Exposing high-res time in workers

I believe it is! When I did my research a few months ago, it was just on
its way in chrome, and I wasn’t sure of the status in other browsers at
that time.

https://code.google.com/p/chromium/issues/detail?id=169318

My primary use cases are:

- physics in web workers need accurate deltas between time steps
- determining “message latency” (time between when a message was
postMessage’ed from worker and received in parent), and compensating when
rendering [1]
- one step closer to an isomorphic api when writing code that can run in a
worker or not

[1]: when experimenting, I attempted sending over the result of
`performance.now()` as a “trigger” for the worker to compute the next
physics tick, but it was impossible to determine how long the message
actually took to be received, AND the browser(s, especially FF) crumbled
when the rate of postMessage approached more than 60 per second (1 msg for
the tick, another for the results of the tick back).

Yip yip,
~ Drew*


On Mon, May 5, 2014 at 4:23 PM, Sigbjorn Finne <sof@opera.com> wrote:

> Den 05.05.2014 17:46, skreiv Domenic Denicola:
>
>  Hi all,
>>
>> I am sitting in an EmpireJS talk by Andrew Petersen, CC’ed, who pointed
>> out on-stage that one of the features he misses inside web workers is
>> high-resolution time. If there's a desire for use-cases, I hope he can
>> chime in.
>>
>>  From a spec perspective, this seems like a pretty easy tweak: I believe
>> the WebIDL these days is [Exposed=Window,Worker]. I assume from an
>> implementation perspective it is not much harder either.
>>
>> What does the working group think?
>>
>>
> Isn't this covered by the Level 2 spec?
>
>
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/
> HighResolutionTime2/Overview.html
>
> (which is shipping in Opera 21 and Chrome Stable now, i.e., M34.)
>
> --sigbjorn
>