Re: Scheduling multiple types of end-of-(micro)task work

On 10/19/2012 12:08 AM, Rafael Weinstein wrote:
> CSS Regions regionLayoutUpdate brings up an issue I think we need to
> get ahead of:
>
>    https://www.w3.org/Bugs/Public/show_bug.cgi?id=16391
>
> For context:
> --------
> Mutation Observers are currently spec'd in DOM4
>
>      http://dom.spec.whatwg.org/#mutation-observers
>
> and delivery timing is defined in HTML
>
>      http://www.whatwg.org/specs/web-apps/current-work/#perform-a-microtask-checkpoint
>
> The timing here is described as a "microtask checkpoint" and is
> conceptually "deliver all pending mutation records immediately after
> any script invocation exits".
>
> TC-39 has recently approved Object.observe
>
>      http://wiki.ecmascript.org/doku.php?id=harmony:observe

(Not sure how that will work with native objects.)


>
> for inclusion in ECMAScript. It is conceptually modeled on Mutation
> Observers, and delivers all pending change records immediately
> *before* the last script stack frame exits.
>
> Additionally, although I've seen various discussion of dispatching DOM
> Events with the microtask timing, CSS regionLayoutUpdate is the first
> I'm aware of to attempt it
>
>      http://dev.w3.org/csswg/css3-regions/#region-flow-layout-events


Could you explain why microtasks are good for this case?
I would have expected something bound to animation frame callback handling,
or perhaps just tasks (but before next layout flush or something).


-Olli



>
> [I think this is wrong, and I'm hoping this email can help nail down
> what will work better].
>
> -------
>
> Strawman:
>
> I'd like to propose a mental model for how these types of work get
> scheduled. Note that my guiding principles are consistent with the
> original design of the the end-of-(micro)task timing:
>
> -Observers should be delivered to async, but "soon"
>
> -Best efforts should be made to prevent future events from running in
> a world where pending observer work has not yet been completed.
>
>
> Delivery cycles:
>
> 1) Script (Object.observe) delivery. This is conceptually identical to
> Mutation Observers.
>
> http://wiki.ecmascript.org/doku.php?id=harmony:observe#deliverallchangerecords
>
> 2) DOM (Mutation Observers) delivery.
>
> http://dom.spec.whatwg.org/#mutation-observers
>
> 3) End-of-task queue.
>
> This would be a new construct. Conceptually it would be a task queue
> like other task queues, except that its purpose is to schedule
> end-of-task work. Running it causes events to be dispatched in order
> until the queue is empty.
>
>
> Scheduling:
>
> A) Immediately before any script invocation returns to the browser
> (after the last stack frame exits), run (1). This can be purely a
> concern of the script engine and spec'd independent of HTML & DOM4.
>
> B) Immediately after any script invocation returns to the browser
> (microtask checkpoint), run (2). Note that delivering to each observer
> creates a new script invocation, at the end of which, (1) will run
> again because of (A).
>
> C) Immediately before the UA completes the current task, run (2). This
> is necessary incase DOM changes have occurred outside of a script
> context (e.g. an input event triggered a change), and is already
> implemented as part of DOM Mutation Observers.
>
> D) Run (3). Note that each script invocation terminates in running (1)
> because of (A), then (2) because of (B).
>

Received on Thursday, 18 October 2012 21:52:42 UTC