Re: Mutation events replacement

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.

Additionally, doesn't this problem occur equally in the mostly-sync
proposal? If someone makes a few mutations and then adds a mutation
listener it appears that the same situation appears.

/ Jonas

Received on Friday, 22 July 2011 23:41:48 UTC