#parallel layout

This fall, I'm working on Servo, a parallel, task-based layout engine and framework being developed at Mozilla. So, I've been reading browser architecture research papers in search for inspiration. This is a complex domain, which makes it quite easy to hide devils in the details. I hope to point out a few of these details, so that others can read these papers more carefully.

(I realize many of these flaws are simply artifacts of a work in progress; that said, there's no reason to believe they will be addressed if nobody raises issues.)

Lies, damn lies, and statistics

The most obvious devil in the aforementioned paper's numbers is the breakdown of CPU time in the browser. Every paper has a different composition, workload, measurement technique, etc. So, some papers (such as this one) claim that CSS selector matching and cascading is not important, while others (such as Leo Meyerovich's work) claim it is more important than layout tree constraint solving.

To me, it's not clear how these numbers are derived. What functions constitute parsing? layout? CSS? rendering? In fact, the WebKit toolkit merges and interleaves many of them to minimize tree traversals. Some parts of the browser precompute results for others. Most notably, the parser prunes a lot of work, and CSS and layout are interleaved. At the least, I would have liked a summary of what decomposition they used, and a process for measuring this consistently (i.e., with no human involved).

The other problem is workload. Replicating their experimental results is impossible, even if their sources were made available (it is not). Live web pages change daily, and how they are loaded depends greatly on network characteristics. Richards et al. are making progress towards better JavaScript and webpage benchmarks, but their work focuses mainly on JavaScript benchmarks.

Correctness and Feasibility

Recent experience in designing Servo's architecture has made me skeptical about hand-waving of details. In this paper, the obvious threat to correctness is splitting up web pages into independent mini-pages, executing in parallel, and combining them. There are not nearly enough details given for this to be reproduced, let alone judged, by browser vendors.

How does DOM dispatch work across independent mini-pages? It is stated that the event target is found across mini-pages, and then the DOM event is created and dispatched in the main page. How can the main page dispatch the DOM element if the mini-page's DOM contains some of the targets? This seems incompatible with having all JavaScript run in one page---unless the JS minipage has DOM bindings for all minipage---in which case, it seems unlikely that minipages can safely execute in parallel.

(N.B. they merge minipages if script needs to access DOM state. This almost seems like the common case to me: DOM event dispatch will need to access every single DOM element between the event target and the page root.)

Can mini pages really be positioned correctly without parent context? This seems unlikely, since the CSS 3 Values module makes it easy for any element to specify widths relative to the containing viewport.

What happens when a new stylesheet or rule is added?

Building up DOM trees in parallel violates the HTML5 parser specification when error cases are encountered (as far as I can tell).

Using an external proxy to instrument/split content is not feasible for HTTPS pages and dynamically created pages (such as those that build the DOM from AJAX responses using JavaScript).

CSS rules cannot be pruned and specialized for mini-pages, as this breaks the CSS Object Model.

Details of synchronizing JavaScript and the DOM are elided. This is worrisome. 

Synchronizing JavaScript and layout results (i.e., .getClientRects, HTMLImageElement.width, and others specified the CSS OM View module) is not even discussed, but is a major constraint for parallel browsers.