Re: [css-display-viewport] Enabling fast layout for web apps via isolation

Some of my coworkers here in WebKit are going to be doing some
experimentation in Jan/Feb to see how much better performance we
really can wring out of something like this.  When we've established
that something like this would indeed be of benefit, I'll bring my
ideas to the group officially.

For now, my unofficial and very rough idea is to introduce
display-inside:viewport, like you have.  The viewport element is
treated as a replaced element with no intrinsic size or ratio, for the
purpose of layout around it.  It imposes strong isolation constraints
on itself (overflow:hidden, positioning root, maybe more), and
slightly different but still very strong constraints on its children
that ensure it's trivial to tell, based on a child's position and the
container's scroll offset, whether the child is painting anything in
view..  It does absolutely no layout - all of its children overlap in
the before start corner by default, and must be positioned by using
transforms.

These constraints should hopefully achieve quite a lot of things for
performance-related optimizations:

1. The isolation constraints on the viewport mean that you can
completely ignore its contents for the purpose of laying out the rest
of the page.  Your draft focuses on this problem.
2. The isolation constrains on the children mean that you can be
conservative in generating and aggressive in throwing away renderers,
so you only have to construct box trees for children that are on
screen or that you predict might be on-screen soon.  This implies some
*very* strong constraints - for example, we'll want to clip
shadows/filters to the margin box, scope counters to the children,
etc.  When you do have to generate a renderer for a child, you can do
it all by itself, without any layout constraints implying that you
have to generate all the preceding siblings too.  This lets us heavily
optimize containers with lots of content, and paves the way to
DOM-level controls that let the browser do the same aggressive
optimizations with the actual DOM nodes - call a method on the
container, passing in a <template> element and a JS array of data, and
you get free automatic element creation/deletion!
3. Requiring layout to be done solely with transforms lets us do an
end-run around a limitation common to all browsers, where layout
starts breaking down when an element gets bigger than 1M-16M (varies
by browser) px in one dimension.  You simply run out of
layout-coordinate space and start losing precision after that.
Transforms are done with doubles, so you can get *much much* bigger
before running into precision errors.  Even if you do hit the
precision limit (at around 1e16), it only affects positioning of the
children themselves; layout within the children can be done in a local
coordinate space with the origin nearby, so it remains stable.

This is the lowest-level primitive version of the idea, and as such is
very manual - you pretty much have to do your layout in script, but
that's precisely the case we're targeting anyway.  I have some plans
to layer some simplistic-but-useful layout modes on top of this, such
as simple vertical and horizontal lists, so that things like the
Twitter timeline can hopefully be done purely declaratively.

~TJ

Received on Thursday, 20 December 2012 19:17:47 UTC