On 9/19/09 2:27 AM, Robert O'Callahan wrote:
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.
The "restyle by traversing the DOM tree" approach would completely solve
this problem.
Right.
Right now it seems to me the only disadvantage of traversing the DOM
tree is that you have to examine every child of an element that has only
a small number of children that need restyling.
That seems to be the main issue, yes. Plus the need to add a bit more
storage to every node to track the restyle hint, etc.
But generally speaking when we reflow or repaint we will examine all those
children's frames
anyway, so avoiding looking at those child nodes doesn't seem like a
major win.
That sort of depends on the exact DOM tree... A full DOM traversal
takes order of 10-20ms on a largish page (e.g. the HTML5 single-page
spec), so it might be ok no matter what.
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?
No, I was thinking of deferring sorting until we actually perform the
restyling.
Sure. We just need to sort before we do frame construction, if we're
trying to coalesce there.
But I think I like the idea of flags in the DOM tree much better.
I do have to admit it has its benefits; this is why I mentioned it. ;)
-Boris
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
