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

On 10/18/12 2:51 PM, "Olli Pettay" <Olli.Pettay@helsinki.fi> wrote:

>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-ch
>>eckpoint
>>
>> 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).

In the spec bug discussion, it was suggested that we use end-of-task or
end-of-microtask timing. When I looked at these options, it seemed to me
that the regionLayoutUpdate event was somewhat close in intent to
MutationObservers. So between those two options, I picked microtask. If
there's a better place to trigger the event, I'm happy to make a change to
the spec.

The current wording may be wrong for separate reasons anyway. The event is
looking for layout changes. For instance, if the geometry of a region in
the region chain is modified, and this causes either (a) overflow in the
last region in the chain or (b) the last region in the chain to become
empty, then we want the event to trigger so that a script can add or
remove regions in the chain to make the content fit correctly. If a task
in the event queue caused the change, then the microtask point after that
task is probably too soon to evaluate whether the event needs to fire. And
if that was the last task in the queue, then there may not be another
microtask happening after layout has occurred.

So what I need is an appropriate timing step for responding to layout
changes. Any suggestions?

>
>>
>> [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#deliverallchangere
>>cords
>>
>> 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 22:20:08 UTC