Some background:
It's common for tests and webpages to bounce a single DOM node in and
out of the tree a bunch of times in a row. Right now we
construct/destroy frames for it each time it's inserted/removed. It
would be nice to not do that.
Webkit implements a limited form of laziness in creating its
RenderObjects. If the insertion is via a DOM call from JS (as opposed
to from the parser, say), then instead of creating a RenderObject they
just flag the node as needing a renderobject created, flag its ancestors
as having such a descendant, and return. At least as far as I can tell.
Then later they walk the tree, limiting to subtrees that have a
descendant needing RenderObject creation, and create the RenderObjects.
It looks like this is the way they handle style changes in general,
actually; the "needs creation" is just a style change value.
In Gecko, style changes are instead handled via a hashtable of objects
to style changes. When it comes to processing the style changes, we
enumerate the hashtable. So order is not guaranteed in particular.
Implementation thoughts on lazy frame construction:
We could adopt an approach similar to webkit's: When a node is inserted
(esp. via the DOM from JS), just post a "create a frame" restyle event,
then process it as normal when processing restyles. This might lead to
lots of restyle events, and frames being constructed in sub-optimal
orders. So it would be nice to coalesce the construction operations
somehow. The questions then are:
1) How to keep track of which nodes need frames constructed?
2) How to actually construct the frames reasonably?
3) Which set of DOM mutations to apply all this to (e.g., should we
coalesce stuff that comes in from the parser?).
-Boris
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
