Robert O'Callahan wrote:
On 24/3/09 6:22 PM, Boris Zbarsky wrote:
On a related note, the eager nature of frame construction and the fact
that some cases reconstruct the parent means that there are situations
where removing a bunch of kids is O(N^2) in the number of kids (each
removal causes a reconstruct of all the kids). I wonder whether it's
worth it to look into posting a restyle event to handle the parent
reconstruct in MaybeRecreateContainerForFrameRemoval and just removing
the frame normally. We can't do that sort of thing as easily on
insertions, since we might not have a good place to put the new frame,
but it'd work for removals...
If it's really that easy, doesn't that mean that lazy frame construction
is also that easy?
Funny you should ask. ;) I did think about that a bit last night,
while I was thinking about the issue above.
Doing fully lazy frame construction is a little scarier for several reasons:
1) Lazy handling of ContentRemoved means that frames are still in
the frame tree at some points for nodes that are no longer in
documents. So if you're accessing the frame tree without
flushing first you need to be pretty careful. Note that above I
propose removing the frames eagerly and just doing the
reconstruct of the parent (to rebuild table pseudos, {ib} splits,
XUL box block wrappers, etc) lazily.
2) Lazy handling of insert/append means having to buffer up the
notifications we saw, then replaying them. But replaying them
against a different content tree might not make much sense (e.g. two
ContentAppended notifications for the same parent), and to really
get a performance win we'd need to intelligently coalesce them
anyway.
I think handling ContentRemoved by removing the frame immediately and
then doing anything more complicated lazily is the way to go long-term;
I don't see much of a win from trying to coalesce removals. I do think
it's worth looking into coalescing inserts/appends, but doing that seems
not quite trivial. On the other hand, my proposal above is a very
simple change code-wise, I think. It'll need a bit of shaking out, of
course.
-Boris
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
