- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 22 Jul 2011 16:40:43 -0700
- To: Olli Pettay <Olli.Pettay@helsinki.fi>
- Cc: 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. 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