Bug 41361 - HTML5 TreeBuilder should attach whole subtrees instead of individual nodes
Summary: HTML5 TreeBuilder should attach whole subtrees instead of individual nodes
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-29 10:44 PDT by Geoffrey Garen
Modified: 2011-05-17 10:53 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Geoffrey Garen 2010-06-29 10:44:02 PDT
The simplest way to do this might be to call recalcStyle() on the root of the subtree. An alternative would be just to rely on the layout timer.

This is a substantial change, but since we're rewriting the tree builder anyway, maybe this is the right time for such a change.

Here are two cases that would definitely get faster if elements attached lazily instead of individually:

1. An element is added to the page but, before it displays, a script removes it from the page. (More common than you might think.)

2. An element is added to the page but, before it displays, another element is added, or a new stylesheet is loaded, changing the first element's layout or rendering.

In both of these cases, the eager attach done by the parser is just thrown away.

I'd also expect improved cache effects from building the render tree in one go.

Concerns about this approach:

1. JavaScript access to rendering-dependent properties. Our design is that any JavaScript accessors that depend on layout should update layout if needed before doing their thing. Any failures in this area are the fault of the accessor. So, in theory, this is either not a concern, or a concern with a set of simple one-off fixes for pre-existing bugs.

2. attach() has side effects for plugins.  Plugins trigger their initialization off of attach(). One solution is to attach plugins before executing any scripts. Another solution is to treat plugin access from script just like any other rendering-dependent access. Another solution is to trigger plugin initialization based on DOM insertion instead of attach().
Comment 1 Adam Barth 2010-07-20 18:19:40 PDT
This doesn't block the master bug because it's not required in this phase.  I'd still like to do this, however.