Closed Bug 1169068 Opened 9 years ago Closed 9 years ago

Update the High Resolution Time API to the latest version of the spec

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla45
Tracking Status
firefox41 --- affected
firefox45 --- disabled
firefox46 --- disabled
firefox47 --- disabled

People

(Reporter: baku, Assigned: baku)

References

()

Details

Attachments

(1 file, 5 obsolete files)

The draft of the spec introduces workerStart and performance.now() in workers.
Assignee: nobody → amarchesini
We should get the spec figured out.  I strongly believe the zero time should have a unified name across windows and workers.
Attached patch time.patch (obsolete) — Splinter Review
Attachment #8612157 - Flags: review?(ehsan)
Comment on attachment 8612157 [details] [diff] [review]
time.patch

It's not clear to me that this matches the spec (e.g. it always returns 0 for a shared worker, no?).

That said, the spec seems entirely unclear to me; I'll post to the list about that.
Attached patch time.patch (obsolete) — Splinter Review
Thanks for spotting this, bz.
Would be nice to have in the spec that, for SharedWorkers/ServiceWorkers workerStart can be lower than navigationStart.
Attachment #8612157 - Attachment is obsolete: true
Attachment #8612157 - Flags: review?(ehsan)
Attachment #8612257 - Flags: review?(ehsan)
Attached patch time.patch (obsolete) — Splinter Review
Attachment #8612257 - Attachment is obsolete: true
Attachment #8612257 - Flags: review?(ehsan)
Attachment #8612258 - Flags: review?(ehsan)
No, that doesn't make sense either, because that's subtracting wall-clock values not TimeStamp values.

What you want to be doing is taking the difference between the CreationTimeStamp() of the WorkerPrivate and the GetNavigationStartTimeStamp() of the navigation timing or so.  But do note the mail I just sent to the spec list a bit ago...
Comment on attachment 8612258 [details] [diff] [review]
time.patch

Clearing per comment 6.
Attachment #8612258 - Flags: review?(ehsan)
Attached patch time.patch (obsolete) — Splinter Review
Attachment #8612258 - Attachment is obsolete: true
Attachment #8622520 - Flags: review?(ehsan)
Attachment #8622520 - Flags: review?(ehsan) → review?(bzbarsky)
Comment on attachment 8622520 [details] [diff] [review]
time.patch

The workerStart thing isn't pinned down in the spec and unlikely to stay in the form it's in right now.  See the public-web-perf discussion.

We should probably wrap up said discussion before implementing this.
Attachment #8622520 - Flags: review?(bzbarsky) → review-
Attached patch time.patch (obsolete) — Splinter Review
Attachment #8622520 - Attachment is obsolete: true
Attachment #8689097 - Flags: review?(bzbarsky)
Comment on attachment 8689097 [details] [diff] [review]
time.patch

>-  // If the time we're trying to convert is equal to zero, it hasn't been set
>-  // yet so just return 0.

Hmm.  So I guess the only caller of this was PerformanceBase::ResolveTimestampFromName, which never calls this function with 0, right?  <sigh>.

>+nsPerformance::CreationTimeStamp() const

I think this should return an actual TimeStamp or "const Timestamp&" or something, not a DOMHighResTimeStamp.  Because otherwise you're using non-monotonic clocks for the values you're working with, which doesn't seem correct.  I filed https://github.com/w3c/hr-time/issues/21 on the spec not being sufficiently clear here.

So you'd return GetDOMTiming()->GetNavigationStartTimeStamp() from this method.

>+PerformanceBase::TranslateTime(DOMHighResTimeStamp aTime,

And here what you'd want to do is to compute the otherCreationTimeStamp across various codepaths (window, various workers) and then do:

  double newTime = 
    aTime + (otherCreationTimeStamp - CreationTimeStamp()).toMilliseconds();
  const double maxResolutionMs = 0.005;
  return floor(newTime / maxResolutionMs) * maxResolutionMs;

It may be worth factoring this clampingto 5us out into an inline method on PerformanceBase, now that we'll have it in three different places...

>+  return aTime + (workerPrivate->NowBaseTimeHighRes() - CreationTimeStamp());

And instead of NowBaseTimeHighRes() you'd just call NowBaseTimeStamp() here to get the otherCreationTimeStamp.

>+  return ts - CreationTimeStamp();

I guess you'd want a CreationTime() method too, which does what CreationTimeStamp() does in your code above, for use here.

>+++ b/dom/base/test/test_performance_translate.html
>+    ok (a > 0, "Time has been translate from a window");

I'm afraid the best you can assert here is a >= 0, especially once the 5us clamping is introduced.

Also, I think this test would be stronger if you compared 0 translated into the subframe to performance.now() captured right before the start of the subframe load.

Also, "has been translated from a window that started loading later than we did".

>+  ok (a > 0, "Time has been translate from a Worker");

Similar comments here.

>+  ok (a > 0, "Time has been translate from a SharedWorker");

And here.

>+++ b/dom/webidl/Performance.webidl
>+  // serializer = {attribute};

We already implement this: it's the "jsonifier" in the partial interface block immediately following.  Just move it up here?
Attachment #8689097 - Flags: review?(bzbarsky) → review-
Oh, and I guess file a followup on changing what the actual time base of a dedicated worker is, right?
Attached patch time.patchSplinter Review
I cannot move jsonifier in the previous block otherwise webIDL gencode will complain about get_timing and get_navigation not implemented in workers.
Attachment #8689097 - Attachment is obsolete: true
Attachment #8689279 - Flags: review?(bzbarsky)
> I cannot move jsonifier in the previous block

Oh, I see.  The jsonifier is mainthread-only right now.

I guess that's OK, since the attributes it would affect are also mainthread-only.
Comment on attachment 8689279 [details] [diff] [review]
time.patch

>+    RefPtr<nsPerformance> performance = aTimeSource.GetAsWindow().GetPerformance();
>+    MOZ_ASSERT(performance);

GetPerformance() can, unfortunately, return null.  Sorry I missed that the first time.

I think it's reasonable to just return aTime in that situation or something; it's not something that should come up in practice in non-malicious usage.  Or we could throw.  Either way.

>+    otherCreationTimeStamp = aTimeSource.GetAsWorker().CreationTimeStamp();
>+    otherCreationTimeStamp = workerPrivate->CreationTimeStamp();
>+    otherCreationTimeStamp = workerPrivate->CreationTimeStamp();

Thse should all be NowBaseTimeStamp(), no?  At least until we get rid of the difference in terms of how Performance.now() and whatnot work on workers.

I wonder how we could add a test that would have caught this....  I guess long-term, when CreationTimeStamp becomes NowBaseTimeStamp(), we can't.

>+PerformanceBase::AdjustTime(double aTime) const

I'd call this RoundTime().

>+++ b/dom/base/test/test_performance_translate.html
>+  ok (a >= 0, "Time has been translated from a Worker that started loading later than we did");

Again, would be better to compare it to a performance.now() call from right before the new Worker() call.

Except I guess that wouldn't work for now while the worker shares our timeline, right?  Maybe add a comment and a todo() to that effect for now.

>+  ok (a >= 0, "Time has been translated from a SharedWorker that started loading later than we did");

This one, though, should be comparable to performance.now() from right before new SharedWorker, right?

r=me with the above fixed.
Attachment #8689279 - Flags: review?(bzbarsky) → review+
https://hg.mozilla.org/mozilla-central/rev/6c466e1e3d71
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
I just realized that we really should have sent an intent to ship.  Done that now.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: