Re: [w3ctag/design-reviews] Task Scheduling (#72)

Some thoughts during discussion in the breakout session:

Potential problem: no opportunity to process input during the rendering loop (which some consider higher-priority than rendering)?
 • Some implementations (i.e., Chrome) were considering processing input at the same rate as the Render-loop, but coalescing multiple input events of the same type (e.g., mouse/touch moves) into a single event (either dropping the others in the queue, or providing the additional data in the single event).

Invariants? What are they?

Background processing: (for things in background tabs, (or potentially in non-visible iframes, etc.) slowing the render-loop frequency (or enabling it to be time-sliced to process foreground work, can lead to increased queue sizes in the background tab, which can lead to 'jank' in the foreground tab when the background tab finally drains all the queues.

Where should certain processing be done relative to where layout is computed? Should be based on how the API might use layout info (e.g., wse layout data vs. set style data):
 • RequestAnimationFrame - Seems like purpose is to write styles (vs. reading layout), thus should ideally be done before computed layout (or you would run layout twice if layout was read in the callback)
 • IntersectionObserver - Purpose is to read layout, thus should be in the pipeline after layout has been done, if styles are written (then layout would be done twice).
 • ResizeObserver - Hmm. Writes styles and reads layout--where to put it?




-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/72#issuecomment-318096091