Participants
Will Hawkins, Emily Hanley, Tim Dresser, Nicolás Peña, Gilles Dubusc, Philippe Le Hegaret, Shubhie Panicker, Ryosuke Niwa, Benjamin De Kosnik, Steven Bougon, Ilya Grigorik, Todd Reifsteck, Andrew Comminos, Nic Jansma, Scott Haseley, Markus Stange, Shweta Joshi
Chair: Yoav Weiss
Next call: 16th May 11am PST
AI: Yoav to send notification to the list on the F2F
Native scheduling API - wanted to update the group.
- Userspace schedulers are limited to framework, app or userspace
- Native scheduler will be able to schedule multiple unrelated entities - shared notion of priority
- Current web scheduling model: input, then rendering, then everything else, then idle
- Everything else is not well-scheduled, one big FIFO
- Rniwa: this model works for blink, but webkit doesn’t prioritize input
- Scott: do you actually prioritize different things?
- Shubhie: probably less prioritization in webkit. Let’s talk more after the presentation.
- Scott: have different task queues, but for a single document, it’s a single task queue
- React scheduler prioritizes specific tasks, but only meaningful in the context of react. The browser is not aware of them
- The MVP plans to resolve that problem.
- Other problems: no unified API, when to schedule frames, clean reads (maybe requestPostAnimationFrame solves that)
- Requirements - unified priorities, above and below the default, separation of API priorities from internal priorities
- Propose new priorities: 8 new levels: immediate, input events, rendering, input, high, default, low, Idle
- React e.g. wants to yield to input, but maybe not immediately
- What do we want to prioritize? Userscript tasks, events, script parsing, etc. Most beyond scope.
- Static or dynamic priority system? Maps uses static, React dynamic
- Browser control? Priorities system? Could go with shared priority queues or isolated ones
- Proposal: start simple. Single set of priorities. Different apps have different requirements and dynamic seems more complex and may not be needed. Also plans to start with unified set of task queues.
- Plan to publish explainer, implement and experiment with, and have partners play with
- Invite all to comment.
- Shubhie: Just creating a postTask based API is probably insufficient. So plan to push more API and integrate script and fetch tags
- Most important is hearing what kind of validation people want to see.
- Ryosuke: From our side, unclear what user facing issues are we trying to solve
- Shubhie: it’s mostly about juggling priorities and deadlines. We tell developers they got deadlines to run their code to keep their apps responsive, but it’s hard for them to achieve that.
- Ryosuke: Is the goal to increase user responsiveness?
- Shubhie: Increase responsiveness for input (100ms), frmae rates (10ms)
- Scott: FIFO gives you some order, and user facing experience metrics depend on that order. And current order is not optimal
- Ryosuke: what are we trying to optimize?
- Shubhie: user input
- Scott: Also loading metrics, scripts can be responsible for rendering
- Shubhie: Also FID
- Ilya: I assume the explainer spells out the motivation
- Shubhie: yes, the explainer has the motivations
- Ilya: Maybe take an AI to read through that and come back with feedback
- Will: When we talk about optimizing for the user, is that the end user or the developer?
- Shubhie: helping the web developer to achieve end-user expectations
- Ryosuke: Sounds like the criteria will be based on the case studies, build something with the new API and measure that
- Andrew: Speaking for React, we wanted isUserPending to make sure task throughput is high. The high level API needs to keep that throughput.
- Shubhie: We’ll get experimentation results from partners.
- Ryosuke: if you have a priority you want to have a priority inversion
- Todd: When we move to dynamic, what will happen?
- There can be priority inversions in case of timeouts. High priority work can get stuck behind low priority work. We also have priority inversion now, where scheduling high priority work is stuck behind everything. So it won’t make things worse.
- Ryosuke: Not worse, but seems like *the* thing we want to solve here
- Scott: the MVP includes a way to change priorities. So you’d be able to build priority systems in userspace based on that
- Shubhie: The maps use-case, when the user is panning the map, the highest priority is fetching the tiles, but user behavior change can mean we need to do something else right now. Developers need a way to indicate priority change
- Scott: With virtual task queues as a subset of task queues, you’d be able to move tasks between the queues. You could create a periodic high priority task that changes priorities. Virtual task queues will enable userspace scripts to change priorities on their own.
- Shubhie: can add scenarios to the explainer.
- Ryosuke: Have you talked to Android scheduler folks? Relying on users to adjust priorities is tricky. In iOS, user interaction is highest priority and adjustments are done automatically. Might be better to define dependencies.
- Ben: Appreciate the context given by Google Maps panning example. Willing to file issues on WICG. Context is super helpful
- Ryosuke: Also would be great to update GH with what was presented.
- Focused on cross-origin concerns and evaluate feasibility through Blink implementation
- So far so good, and crossorigin script situation uses current infra
- Main issues
- Symbolization map before profiling is fairly expensive - CPU and memory
- Trace sizes are about what we expected
- Testing is a bit challenging - no SLA to what sampling rate
- Either always build the codemap but expensive when not used
- Lazily building it is not great, as it’s done on the VM thread. Can also leak data
- 200-300ms on high end desktop machine
- Greedy is best, if we know we need it
- Maybe declaring it through feature policy. Since it’s restricted to frames, it kinda works
- Increases the overhead of deploying that.
- Ilya: the flow - site operator sets a policy that enables the profiler?
- Andrew: yeah
- Ilya: Why not through JS?
- Andrew: because the creation stops the VM and can leak info?
- Todd: Is that a Blink implementation issue?
- Andrew: Talked to Markus
- Markus: It might be possible to avoid it, but Firefox will have the same problem
- Todd: Chakra could have done that, but not sure that
- Yoav: header registration may be enough, so Feature Policy may be an overkill
- Tim: Slightly different as we want to enable measurement, not necessarily start it
- Andrew: Not married to FP
- Trace format: Form of structural compression. Do we need to add gzip or other compression. Deduping URLs was a big win. Gzip blobs may not be great for everyone, as some consumers may not need some of the trace.
- Yoav: gzip in the browser may be a good complement to that
- Andrew: have success with a wasm impl of snappy compression
- Trace sizes - 22KB gzipped
- Ilya: doesn’t seem too scary
- Nic: 22KB gzipped is on the upper end of what we can get away with
- Tim: what about the 10ms sample rate? You can get away with slower sampling
- Andrew: yeah, measured worst case scenario
- Testing - spec doesn’t provide guarantees to sampling rate
- Yoav: You can maybe enforce sampling using a webdriver API
- Andrew: sure. Web driver sounds good. Would be better if we could test directly
<out of time>