W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Mutation events replacement

From: Adam Klein <adamk@chromium.org>
Date: Thu, 21 Jul 2011 18:26:49 -0700
Message-ID: <CAEvLGc+gJKFi_XY5JkcJxJZs-d8_M9pNxWCsSR=4pbpEZVaY_Q@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Olli Pettay <Olli.Pettay@helsinki.fi>, Boris Zbarsky <bzbarsky@mit.edu>, Dave Raggett <dsr@w3.org>, public-webapps@w3.org
On Thu, Jul 21, 2011 at 4:30 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Thu, Jul 21, 2011 at 8:19 AM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
>> On 07/21/2011 06:01 PM, Boris Zbarsky wrote:
>>> On 7/21/11 5:08 AM, Dave Raggett wrote:
>>>> Thanks for the explanation. Apps would need a way to disable
>>>> notifications during such animation sequences, and would be able to find
>>>> another means to serialize the animation (at a higher level).
>>> I'm not sure I trust apps to do that, which is why I think the default
>>> behavior should be that they just don't get the information.
>>>> This raises the question is unregistering and re-regtistering a mutation
>>>> notification handler cheap or do we need an alternative mechanism for
>>>> temporarily suspending notifications?
>>> Olli is better able than I to answer this for Gecko.
>> In the current WIP patch for mutation event replacement registering and
>> unregistering listeners is cheap, and if there are no listeners,
>> performance isn't affected at all.
>> This is with the sync approach.
>> If async approach is taken, listener handling becomes significantly
>> more complicated. What if the listener is added after the mutation has
>> happened, should it be called? If not, then we need to keep a list of
>> changes for all the listeners separately.
> Hmm.. the most trivial implementation is to keep different lists for
> different listeners no matter what.
> However maybe it's worth allowing listeners to be able to share
> mutation objects? Is that what you were thinking? That might be good
> for performance since it'll create fewer objects, but it'll also add
> more complexity since it requires more bookkeeping.
> Though note that the list of mutation objects will have to be
> per-listener no matter what (i.e. both in the mostly-sync and the
> almost-async suggestions) since different listeners will be observing
> different parts of the tree and thus will see different set of
> mutations.
> The simplest solution that I can think of is to say that the
> addMutationObserver function doesn't take effect until at the end of
> the task. So any listener registered during a task won't get
> notifications until at the end of the following task.
> There are other solutions that we could use, but they seem much more
> complex and so I'd rather avoid them unless there's a good reason to.

This is only complex because you're coalescing the mutations, right?
In Rafael's original proposal, each mutation would result in a single
immutable mutation record, so the semantics would be to "deliver" (by
appending to a queue associated with each observer) a mutation record
to any currently-registered observers.

Or is there some other concern with beginning notifications partway
through a task?

- Adam
Received on Friday, 22 July 2011 01:27:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:23 UTC