Ross McIlroy, Ryosuke Niwa, Thomas Kelly, Steven Bougnon, Yoav Weiss, Phillipe Le Hegaret, Nicolás Peña, Ilya Grigorik, Nic Jansma, Will Hawkins, Subrata Ashe, Benjamin De Kosnik
Next call
requestIdleCallback
- Ross: spec bug, have a PR that should address it
- Ryosuke: why doesn’t each event loop have a list of idle callbacks?
- Instead of associating with group of similar agents, have it be connected to agent that similar agents share
- AI: Ryosuke to followup on PR with suggested approach
- We might want to PR whatwg spec to add concept of idle queues
- Ryosuke: this should talk about event loop and task sources
- … anytime there is a pending task, we should not be scheduling
- Ross: this issue is about predicting the deadline
- Ryosuke: we should explain how to predict this
- as is, it’s completely UA defined
- Yoav: as an upperbound, time until next timer to fire?
- Ryouske: what about web audio or media that schedules rIC. Right now the spec doesn’t talk about them, and the only thing WebKit can implement is timer predictions.
- Ross: for Chrome.. We’re making a forward looking prediction
- … we only look at already queued timers
- … for each task queue that we have, take the min
- … we also take into account our compositor decision about next frame
- Yoav: if high priority task lands, tough..
- Ross: right, once we’ve started executing we can’t do anything. We support bailing before calling the callback if we see things have changed. But called code can query deadline and yield if the time period changes to zero.
- Ryosuke: is this behavior specced?
- Ross: yes, step 1 in 6.2
- Ryosuke: It should explicitly say “if any task source’s task is being queued”. I’ll file a bug about that.
- Ross: for the actual deadline, did you discuss it?
- Yoav: you mentioned tasks queued to run in the future
- Ryosuke: what are future scheduled tasks — e.g. web audio?
- I would probably just check for timer
- Ross: Media and webaudio are probably ones. But not highly familiar with them.
- Yoav: Can’t we find what those tasks are from Chromium’s and Gecko’s implementations?
- Ross: one gotcha here is that Webkit uses Grand-Central-Station, whereas for Firefox and Chrome we have our own scheduler.
- Ben: clarification on pending tasks
- Ross: HTML spec does not have a good definition
- In Chrome we have multiple prioritized queues, within the queue the tasks are not prioritized
- Yoav: and it’s hard to traceback the scheduling code from the scheduler itself, right?
- Ryosuke: we’d probably just look at the timer
- we can’t query raF, that’s owned by core animation
- Ross: we kinda have similar problem, we rely on browser process to tell us
- … we know what is expected, we speculate based on frame frequency
- Ryosuke: we can also do that, I guess
- Ross: … fundamentally, it’s a prediction and heuristic
- … the definitive bit here if+when task is scheduled, resetting to idle time to 0 should be specced more concretely
- set to 0 when task is scheduled
- Next rendering opportunity, even if speculative
- UA-defined timers to make the prediction
- Ryosuke: we should probably simplify the spec to talk about timers and next rendering opportunity (instead of talking about rAF), but drop e.g. discussion on web audio that we’re not properly defining
- Ross: rAF is defined in terms of next rendering opportunity, that sg. We should still keep rAF as a note.
- Yoav: ok, and get rid of audio, etc.
- Yoav: So to recap: We need to define the list of available timers, the next rendering opportunity, and UA-defined timers (and move all the current list as a note under that).
- AI (Ross): Specify setting deadline to zero.
- AI (Yoav): Specify language around what the deadline value is