-
Notifications
You must be signed in to change notification settings - Fork 59
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
Investigate adding dedicated task sources #221
Comments
The HTML spec leaves the task queue prioritization to implementations. I believe an implementation is most of the time in the best position to determine which task to run and when, all things considered, see https://html.spec.whatwg.org/#task-source. In normative prose https://html.spec.whatwg.org/#event-loop-processing-model this is simply:
While we currently do not force a particular task to be of higher priority, requestIdleCallback API provides means to explicitly request a particular task to be executed only during the idle time between the frames. If used appropriately, this API will help keep jank away in use cases that involve sensors too. |
Agreed. The idea wasn't to specify prioritization here, but eventually to provide hooks in the spec(s) to make that easier, for example by using two different task source, one when latency is critical and one when it isn't.
That seems like an orthogonal issue. |
Moving to Level2. There are ongoing activities related to throttled / unthrottled / suspendable task sources, we should definitely investigate those concepts in relation to Sensors. |
This might be useful (or not?) to enable prioretizing sensor queues, maybe even between different types of sensors.
Need to investigate how this is handled at the spec and implementation level
The text was updated successfully, but these errors were encountered: