One question: when an element is removed from the document, should we
remove the element from mPendingRestyles immediately? Right now it looks
like the element is kept alive until we next process restyles, which
could cause an arbitrary amount of memory overhead.
Another question: does mPendingRestyles have any advantages over the
Webkit approach? I guess DOM tree traversal might be a little slower
when you have elements with many children and only a few nodes to
restyle. And I guess it wouldn't work with the way we currently do
native anonymous content. But does it matter? I guess it also wouldn't
work with multiple presentations, but Olli's patch to make that go away
is nearly finished.
A related question: right now, is there anything that quashes restyling
of an element when it has an ancestor that has reconstructed (or will
reconstruct) its frame subtree?
On 19/09/09 5:50 AM, Boris Zbarsky wrote:
1) How to keep track of which nodes need frames constructed?
2) How to actually construct the frames reasonably?
Currently we walk mPendingRestyles and copy the elements into a list.
While we're doing that, we could populate an auxiliary hashtable that
maps an element to a set of its children which may need frame creation.
Then we could walk that hashtable and for each element, scan its child
list locating the indices of the children needing frame creation, and
issuing ContentInserted or ContentAppended notifications along the way.
I presume because we sometimes need to reconstruct frames for
containers, e.g. WipeContainingBlock, there is a preferred order to
visit the elements whose children need frame creation, but what is that
order? Maybe it's not worth computing.
Rob
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
