On 25/3/09 2:34 AM, Boris Zbarsky wrote:
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.
I always imagined that lazy frame construction would be just that: lazy
construction, with destruction remaining eager.
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.
OK.
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.
I agree.
Rob
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
