Re: Mutation events replacement

On Tue, Jul 5, 2011 at 5:51 PM, Ojan Vafai <ojan@chromium.org> wrote:

> On Tue, Jul 5, 2011 at 5:36 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:
>
>> On Tue, Jul 5, 2011 at 5:27 PM, Rafael Weinstein <rafaelw@google.com>wrote:
>>>
>>> It seems like these are rarified enough cases that visual artifacts
>>> are acceptable collateral damage if you do this. [Put another way, if
>>> you care enough about the visual polish of your app that you will put
>>> energy into avoiding flickr, you probably aren't using alert and
>>> showModalDialog anyway].
>>>
>>> Also, it's up to the app when to do it, so it's entirely in its
>>> control (and thus avoid visual artifacts).
>>>
>>
>> Given that we don't provide an API to control paint in general, I'm not
>> convinced that we should add such a requirement in the DOM mutation event
>> spec.
>>
>
> Many of the use-cases for mutation events (e.g. model-driven views) are
> poorly met if we don't give some assurances here.
>
>
>>  Note that this is a problem with both proposals. Work done in (at
>>> least some) mutation observers is delayed. If a sync paint occurs
>>> before it, it's work won't be reflected on the screen.
>>>
>>
>> Right.  Maybe we can add a note saying that the user agents are
>> recommended not to paint before all mutation observers are called.  I don't
>> think we should make this a requirement.
>>
>
> There may be a middle ground that isn't so hard to for browser vendors
> implement interoperably. Can we require no repaint except in the presence of
> a specific list synchronous API calls? I'm sure that's too simplistic, but
> I'm hoping someone with more experience can chime in with something that
> might actually be a plausible requirement.
>

HTML specifies to a limited extent when painting can happen with regard to
what it defines as tasks:

http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#processing-model-2

See step 5 - "update the rendering" is equivalent to painting.  Ignoring
step (2) which relates to the storage mutex, this description is accurate.
 No browser updates the rendering after invoking every single task, but I'm
pretty sure that no modern browser updates the rendering at any other time.
 Note that a few APIs such as showModalDialog() invoke this algorithm:

http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#spin-the-event-loop

which effectively starts up a second event loop within the processing of a
task, meaning that the browser can paint while the task that resulted in the
showModalDialog() call is still running.  Authors who are using
showModalDialog() are being extremely user-hostile so I don't think we need
to accomodate them.

One question I have with regards to the proposed processing model is whether
to define this in terms of entering script or in terms of 'tasks' in the
HTML sense.  For example, asynchronous DOM events are typically set up by
queueing a single task to fire the event, but there might be multiple event
listeners registered for that one event that would all be fired as part of
the same task.  If we were to define things in terms of tasks, then I think
Rafael's proposal is similar to extending step 4 "provide a stable state" of
the event loop algorithm in order to notify observers before proceeding to
step 5.  This would mean that if multiple click handlers were registered on
an element and the user clicked on it, all of the event handlers would run,
then the mutation observers would run, then the browser would be free to
paint if it chose to.  An alternative approach would be to hook on calling
in to script (
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#calling-scripts)
and run the observers after each script invocation.  This means that if
multiple handlers were registered for an event then the first handler would
be invoked, then observers notified, then the second handler invoked, etc.
 It would still have the property that the observers would always run before
the browser painted so long as no script spun the event loop.

I hope this helps.  This has been a long thread and I haven't had a chance
to fully digest all of it, but I'm really happy that people are taking a
serious look at this problem.
- James



> - Ryosuke
>>
>
>