On Jul 3, 2013, at 6:07 PM, David Herman <dher...@mozilla.com> wrote:
> Seems like the hard part of this is that you can't predict when JS will > modify the DOM or CSS in ways that break you out of a subset. That makes the > asm.css idea -- particularly the part about "snapping" into a guaranteed fast > path with no fallback once you can prove you're in it for good -- harder, no? > My understanding of the layout semantics is that layout is 'atomic' wrt JS. Thus, the set of active CSS properties for a tree/subtree can be known at all time, and so several types of passes can be possible. A cool implication is that, depending on how the data representation works, the layout algorithm can cheaply adapt at runtime based on the active feature set. Unlike asm.js, I'm not sure if just one subset makes much more sense than multiple. (It's not a big issue in the case of an engine generator, but for Servo's manual one, it is more so..). The most important subsets are probably some form of: a) 'concrete' -- fully absolute positioned, very few actual constraints (e.g., just text?) b) 'isolated' -- some sort of independent block formatting context for the root. c) 'mixed' -- I can see there being 'nice' subsets as well, such as no floats. CC'ing Eric. Opera's MAMA analysis of CSS features used in 1MM sites was pretty interesting wrt all of these. I can imagine a reactionary subset based on results like MAMA's rather than the more principled subsets above. > But speculating for high-performance subsets with a fallback to the more > general case is tried-and-true. The above can be done via simple profiling, e.g., from hooking into the parser and DOM. We've bounced around true 'value speculation' for layout, which may be a big deal. For example, even if there are floats, they are mostly used for menus rather than inline images. That couldn't be figured out ahead of time, and depending on how floats are computed at runtime, an aggressive layout schedule may have to turn into a less aggressive one. I'd be cautious about going down this road, however, as it seems like a maintenance nightmare without tool support. _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
