-
Notifications
You must be signed in to change notification settings - Fork 19
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
Rely on HTML spec for deadline computation #95
Conversation
In conjunction with whatwg/html#7166 Instead of defining the idle period deadline in prose, rely on the event model processing in the HTML spec to provide a more precise computation of the current idle period deadline. This is accomplished by passing a `getDeadline` algorithm from the HTML spec to this spec when starting an idle period, and re-computing that deadline between idle callbacks, or when `timeRemaining()` is called. This ensures (more formally) that adding timeouts that expire before the end of the idle period, or `requestAnimationFrame` calls from within the idle period, which currently are specified to fire before the next idle tasks due to event loop priorities, will also be reflected when calling `timeRemaining`. Closes #71
<var>getDeadline</var>, an algorithm that returns a {{DOMHighResTimeStamp}}: [[HR-TIME]] | ||
|
||
<p class="note">The algorithm is called | ||
by the <a data-cite="html#event-loop-processing-model">event loop processing model</a> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: If you have data-cite="html...
it means something is probably not right (or needs to be exported from HTML!).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(unless it's a heading 😅 ... as I've not implemented xrefs for those in ReSpec yet!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, this was here before and I've moved it around
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only gave this a "respec review", as I'm not very familiar with requestidlecallback... however, if you want a proper review, I can dive a little deeper in requestidlecallback.
Not necessary, we will discuss it in TPAC and people more familiar with it can review together with the corresponding HTML-spec changes. Thanks for the editorial review! |
@yoavweiss I think this is ready for an actual review, now that the corresponding HTML PR has landed. |
Co-authored-by: Marcos Cáceres <marcos@marcosc.com>
Co-authored-by: Marcos Cáceres <marcos@marcosc.com>
Co-authored-by: Marcos Cáceres <marcos@marcosc.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@marcoscaceres any changes still requested? |
No, apologies for the delay. |
In conjunction with whatwg/html#7166
Instead of defining the idle period deadline in prose, rely on the
event model processing in the HTML spec to provide a more precise
computation of the current idle period deadline.
This is accomplished by passing a
getDeadline
algorithm from the HTMLspec to this spec when starting an idle period, and re-computing that
deadline between idle callbacks, or when
timeRemaining()
is called.This ensures (more formally) that adding timeouts that expire before
the end of the idle period, or
requestAnimationFrame
calls fromwithin the idle period, which currently are specified to fire before
the next idle tasks due to event loop priorities, will also be reflected
when calling
timeRemaining
.Closes #71
Preview | Diff