Boris Zbarsky wrote: > [EMAIL PROTECTED] wrote: > > My question is how to fix this. My guess is that I might be able to > > tell gecko/gtkmozembed that I'm going to be doing a whole bunch of > > updates, do the updates, and then tell gecko that I'm done. > > nsIDocument has an API for this (BeginUpdate/EndUpdate).... It's not frozen > or > anything, but maybe it'll help a little bit in your case.
I'll try this. > > Do you think this is what's causing the slow downs we're seeing? > > Not very likely. A lot of the things that BeginUpdate/EndUpdate actually > coalesce are coalesced even without them (e.g. layout, style changes, etc). > As > long as your application is not using CSS quotes or counters, > BeginUpdate/EndUpdate won't help you that much. Yeah, I thought so, but maybe somehow the coalesced items are getting unspooled by something I'm doing? > Is there a consistent piece of code that's being slow? If so, I'd be > interested > in seeing it (and how it differs from the non-slow code). Yeah, that's the weird thing. It's the same code but some race condition differs. I don't know what the difference is in the different timings. The function we're having trouble with should be near here (assuming there haven't been too many edits.) We call this function over and over and over again from python. https://develop.participatoryculture.org/projects/democracy/browser/trunk/tv/platform/gtk-x11/frontend_implementation/MozillaBrowserXPCOM.cc#L137 Thanks for the info. I'll try BeginUpdate/EndUpdate. _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
