-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is PressureRecord.time a timestamp or a time that is relative to timeOrigin? #257
Comments
Currently this is what the spec says, but we can change to something else if that makes more sense. a [[Time]] value of type DOMHighResTimeStamp, which corresponds to the time the data was obtained from the system, relative to the time origin of the global object associated with the PressureObserver instance that generated the notification. |
About the implementation (on Chromium): The difference is that PerformanceObserver is getting the time from "TickClocks class", which is for iframe (e.g), relative to the time of creation of the frame, threfore the number is smaller in your experience. In ComputePressure it s the current time. (Which might be affected by the system). Unless mistaken, they are both DOMHighResTimeStamp. It makes no difference to us if the observer is run from a worker or a frame since the sample time is fetch from the same backend. I need to test out what would be the effect if using TickClocks instead of Time class in Chromium. Actually it would prevent the possible issue from system adjustment. |
I guess the main thing I want to understand (for the documentation) is: What is
If the answer is 1), then I think the spec text is confusing as it talks about being "relative to the time origin" |
@Elchi3, you are correct, the implementation is relative to the Unix Epoch (January 1, 1970, UTC). The question is now, what would make more sense? I don't think that 2) as defined in performance.timeOrigin, makes sense for Compute Pressure, since it would be useful to have the same origin for workers and window, without manipulation of the timestamp. @Elchi3, if I understood, your concern is more about the wording of the specification. |
Maybe something like this? (I'm no spec editor at all)
|
Yes, Thanks for pointing out the discussion! |
fwiw, I don't know the answer to this. My feeling is that in the Performance APIs, developers are used to working with document-creation-relative-time and not epoch-relative-time. I guess currently it would be mixed time information if you use compute pressure with other time markers. For example:
So if we had the same time origins, the advantage would be that the compute pressures could all be lined up in a timeline with other performance-related events.
|
I also assume that if you want epoch you can take the relative number and add it to the time origin? |
Adding @yoavweiss here, as he should be able to give us advice on the best way forward:
What do you recommend Yoav? |
Yes! performance.timeOrigin + computePressureRecord.time = epochtimestamp (if computePressureRecord.time would be time origin relative) And for synchronization between window and worker, the timeOrigin property helps you to translate as well. See this example: https://developer.mozilla.org/en-US/docs/Web/API/Performance/timeOrigin#synchronizing_time_between_contexts |
So this basically means that the spec is in good shape, but we have an implementation bug. Might make sense to add some examples to the spec or mdn though :-) |
I think it'd be better for y'all to more strictly define what timestamp y'all want to get. The current relative timestamp seems like a reasonable choice for what you're after. |
so something along the lines of? a [[Time]] value of type DOMHighResTimeStamp, representing the [=current relative timestamp=] of the [=relevant settings object=] associated with the PressureObserver instance that generated the notification. |
That sounds about right, assuming that the PressureObserver has an associated environment settings object. |
Indeed, that would be the relevant settings object of that instance. Tried to update the text above :-) |
Specs are clear, implementation is not. It is now tracked here: crbug |
closing spec issue, now that we have an implementation bug |
I'm reopening the spec issue because the wording should still be adjusted here:
I think what needs to happen is something similar to how Generic Sensors handles timestamps (https://w3c.github.io/sensors/#update-latest-reading):
|
(Using the terms from the HR-time spec the right way is always confusing to me, so @yoavweiss is very welcome to correct the above, which would also lead to a fix or two in the Generic Sensors spec :-) |
^^ @noamr I think we want the timestamp to be relative to the time origin (so maybe fix the Chromium implementation). |
Follow-up to #274, related to #257. The wording used in #274, which mentions platform-specific timestamps, made more sense in the context of the Generic Sensor API spec, as multiple platform-specific sensor APIs provide samples with timestamps in a platform-specific format that needs to be converted. Of the OS-provided telemetry APIs, however, only Windows optionally provides samples with a timestamp. As such, it makes more sense to define a timestamp using the monotonic clock's unsafe current time instead. Aditionally, the accompanying note was rewritten to indicate that the same value should be used for all globals, otherwise the same sample would end up with different "raw" timestamps in different frames/workers.
…eck (#279) Follow-up to #274, related to #257. The call to the "passes rate test" algorithm should use `timeValue` rather than `timestamp`: the former is what is stored in `PressureRecord.[[Time]]`, so it makes sense to compare values that have been similarly coarsened and converted to a relative time.
Follow-up to #274, related to #257. The wording used in #274, which mentions platform-specific timestamps, made more sense in the context of the Generic Sensor API spec, as multiple platform-specific sensor APIs provide samples with timestamps in a platform-specific format that needs to be converted. Of the OS-provided telemetry APIs, however, only Windows optionally provides samples with a timestamp. As such, it makes more sense to define a timestamp using the monotonic clock's unsafe current time instead. Aditionally, the accompanying note was rewritten to indicate that the same value should be used for all globals, otherwise the same sample would end up with different "raw" timestamps in different frames/workers.
The spec says:
In Chrome Canary I'm getting timestamps, though. (e.g., 1712050826399.263, so maybe it is a Chrome bug?). I was expecting a smaller number similar to when I call performance.now().
Follow up question: If I should be seeing relative time stamps, do they respect performance.timeOrigin so that I could sync times between window and worker contexts?
The text was updated successfully, but these errors were encountered: