- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Sat, 06 Jun 2015 01:33:00 -0400
- To: Justin Rogers <justrog@microsoft.com>, Ilya Grigorik <igrigorik@google.com>
- CC: Jonas Sicking <jonas@sicking.cc>, "public-web-perf@w3.org" <public-web-perf@w3.org>, Przemysław Pietrzkiewicz <ppi@google.com>
On 6/6/15 1:13 AM, Justin Rogers wrote:
> I'm a little bit confused. Shouldn't the workerStart just look at the time origin of the global object of the worker instance?
That depends on what we want out of it.
> I'm not familiar with the wording of incumbent settings object, so maybe I'm confusing something.
The incumbent settings object is, loosely speaking, "the settings object
corresponding to the global of the code that made the call into the API".
> If this is possible then workerStart is the difference between the time origins of the worker instance global and the attached WorkerGlobalScope global.
No, that's precisely what it's not if we do the incumbent settings
thing. What you propose would allow you to convert the
performance.now() time from inside a worker to something sane only if
you happen to know which global's constructor the worker came from (and
hence can use that global's performance.now() or can measure its offset
from yourself and use your own performance.now()).
Again, the point of the incumbent settings thing is so the comment in
the following code is true no matter what global the worker w came from:
w.onmessage = function (e) {
var timeFromWorker = e.data;
var timeInOurTimeline = timeFromWorker + w.workerStart;
// timeInOurTimeline can be compared to performance.now() calls
// made in this function.
}
Making workerStart just look at the time origin of the global the worker
instance is associated with does not satisfy the comments in that code.
Maybe that's OK, of course. I'm just saying if we _do_ want that
property then we should use the incumbent settings object.
-Boris
Received on Saturday, 6 June 2015 05:33:32 UTC