Re: Mutation events replacement

On Thu, Jul 21, 2011 at 6:26 PM, Adam Klein <adamk@chromium.org> wrote:
> 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.

I think that's the only reason yes.

/ Jonas

Received on Friday, 22 July 2011 22:55:40 UTC