-
Notifications
You must be signed in to change notification settings - Fork 24
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
Comments on "Define 'relative high resolution time'" #96
Comments
Seems like we phrased it in a way that's not clear. Should've followed https://infra.spec.whatwg.org/#declaration
"current high resolution time" is called from now(), so I assumed we can use "context object" there. What's a better way to define this? /cc @igneel64 |
@yoavweiss you would pass "this" as an argument in from |
One thing that's not clear to me is how |
That's a good point, though I think ideally we add noise directly at the source of the time signal, to allow exposing it through other types in the future. |
Note to self: "current high resolution time" is also called from https://wicg.github.io/element-timing/#ref-for-report-image-element-timing%E2%91%A0, so it makes sense to pass along a global. @npm1 - what you're suggesting could be an evolution path towards #93 (where we add explicit rounding/jitter, and then change it for isolated contexts) |
It's used in more places than that. Other examples:
|
@annevk As @npm1 and @yoavweiss mentioned, we would want the definition of Do you think that a definition like the one below would be enough ? (small change on this)
Does this case conform if we define what the |
Definition based on https://infra.spec.whatwg.org/ spec & reform 'current high resolution time' to accept a global argument
Definition based on https://infra.spec.whatwg.org/ spec & reform 'current high resolution time' to accept a global argument
Correct algorithm definition & 'current high resolution time' reform - Fixes #96
Continuing discussion from #97 here:
|
@annevk what we're aiming for the design here is to have a single place where jitter/rounding can be introduced, and as a result, a single place where these can be relaxed for "isolated" contexts (which can't load resources that are not CORP enabled). Looking again, I think the first location in the DOM spec can simply call "current high resolution time". It's just the third location that would have to be a bit more handwavy until a refactoring that defines the point in time that needs to be recorded is done. But given that it's already handwavy now, I'd prefer to make other callers more precise in the interim. Does that make sense? |
Let's start with that I agree on the goals. I also appreciate you reopening this issue. So I can see how most cases could be refactored to use "current high resolution time", which given a global object, returns a (potentially jittered/rounded) double. However, the OS/kernel timestamp case cannot. There what we want, is an algorithm that given an external timestamp and a global, returns a (potentially jittered/rounded) double. Even in a future where we'd capture the OS timestamp at a more appropriate time (harhar). It's also not entirely clear to me whether HTML's So I still see the need for three primitives:
(And I guess there's the primitive of the timestamp on OS/kernel events, but that's really for various event specifications to formalize better.) cc @domenic |
That all sounds reasonable. I opened #99 to expose "unsafe now". |
@annevk - I believe this is all properly handled now with unsafe shared current time, current hr-time, and relative hr-time. WDYT? Can we close this? |
Yeah, I suspect if there's follow-up that's better served with new issues at this point. Thanks for working on this! |
Looking at the diff of #95 there's a couple things I don't really understand:
The text was updated successfully, but these errors were encountered: