On 9/19/09 2:42 AM, L. David Baron wrote:
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. 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.
We could avoid this relatively easily by using an out-of-band tree
(much like the reflow tree that we had before the reflow branch
landed). This is what I propose in
https://bugzilla.mozilla.org/show_bug.cgi?id=479655
My concern there is that we then have to maintain this out-of-band tree
on DOM mutations. Would it basically consist of a subtree of the
(flattened, with anon content, etc) DOM that contains only nodes needing
restyling or their ancestors? If so, updating on mutations might not be
too bad...
(Another advantage such an approach might have is that we'd have
more room for storing the various types of restyling we might want
to do, if we want to differentiate more cases in order to optimize
them.)
Right. Webkit stores an enum representing the restyle type in all
nodes, I think. If we want to avoid the word-or-so-per-node cost of
that, we'd need to do it out-of-band.
-Boris
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
