On Thu, Jul 21, 2011 at 4:30 PM, Jonas Sicking <jo...@sicking.cc> wrote: > On Thu, Jul 21, 2011 at 8:19 AM, Olli Pettay <olli.pet...@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