Re: Mutation events replacement

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.

/ Jonas

Received on Thursday, 21 July 2011 23:31:34 UTC