On 9/18/09 5:17 PM, Robert O'Callahan wrote:
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.
I think we should do that, yes. That won't help if the element's
_parent_ is removed, but it should help the common "bounce an element in
and out of the DOM" case.
Another question: does mPendingRestyles have any advantages over the
Webkit approach?
This is a really really good question. ;) I don't know. They have
very different pathological behaviors. I would not be averse to trying
the webkit approach, in general, and seeing what things look like.
And I guess it wouldn't work with the way we currently do
native anonymous content. But does it matter?
I suspect no; we shouldn't really be directly restyling native anon
content, I would think... That's not to say someone like editor doesn't
do it, of course.
We'd need to walk the XBL flattened tree, of course, not just the DOM.
That makes the traversal a little slower, but hopefully not much.
I guess it also wouldn't
work with multiple presentations, but Olli's patch to make that go away
is nearly finished.
Right.
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?
We quash restyling due to possible style changes (as in, we don't
ReResolveStyleContext on subtrees rooted at elements that ended up with
a reconstruct hint), but we don't quash explicitly-posted hints of the
sort that I was thinking of here.
Note also https://bugzilla.mozilla.org/show_bug.cgi?id=479655#c0 might
be relevant here.
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.
Sorted in content order or something?
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.
Hey, if we switched DOM's child storage we wouldn't need the "locating
the indices" bit... ;)
But yes, this could work; I just worry about the performance. I guess
it might not be any worse than the simple thing.
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.
That's hard, yeah. I think the only things we need to make sure of if
we want to do coalescing "right" are:
1) We construct frames for kids of a given node in DOM order.
2) We have a ContentInserted version that inserts a range of nodes,
not just a single node (just like ContentAppended, and with similar
fallbacks if there are multiple insertion points, etc).
#1 is basically needed to make #2 work reasonably.
-Boris
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
