Re: [css-regions] performance of regions fragmentation

On Jan 23, 2014, at 6:49 AM, Alan Stearns <stearns@adobe.com> wrote:

> On 1/22/14, 10:41 PM, "L. David Baron" <dbaron@dbaron.org> wrote:
> 
>> On Tuesday 2013-10-29 12:14 -0700, Alan Stearns wrote:
>>> On 10/29/13 11:24 AM, "L. David Baron" <dbaron@dbaron.org> wrote:
>>>> Agreed, but I think the underlying primitives we expose to do that
>>>> should actually be more like primitives -- they shouldn't involve
>>>> things like implicit multi-pass layout (which isn't in the things
>>>> you cite that are built on top of them).
>>> 
>>> Please note that multi-pass layout is only required IF there is a region
>>> that is sized by its content AND that region is not the last region in
>>> the
>>> chain. There are plenty of places for optimization in the actual
>>> implementation - the spec takes the conservative route and describes the
>>> worst-case scenario an implementation needs to support. Section 7.3
>>> encourages optimizations, and note 12 allows for even more complicated
>>> layout steps if an implementation wants to go down that path.
>> 
>> I don't think this is good enough, especially for a primitive, as I
>> described in
>> http://lists.w3.org/Archives/Public/www-style/2014Jan/0339.html
>> 
>> (Sorry, in hindsight perhaps I should have put that reply in this
>> thread and put a pointer in the other thread.)
> 
> No worries. I think this is a very important discussion to have, so I’ve
> started a new thread and will copy from your other reply.
> 
>> There's been a movement lately (associated with the Extensible Web
>> Platform movement [1], which I have both positive and negative
>> feelings about), to make CSS Regions the primitive on top of which
>> we explain how other CSS features work.
>> 
>> I think CSS regions make a very poor primitive because they have
>> very poor performance in interesting cases.  Rather than always
>> having a simple and fast behavior, they have behavior that requires
>> multiple-pass layout in some cases (especially when combined with
>> other features like CSS Exclusions).
> 
> I disagree with your characterization of ‘very poor performance’ - what we
> have in the specification is there specifically to limit the performance
> implications of fragmentation in edge cases. The point of section 7 is to
> optimize for performance, and limit the requirements to two-pass layout
> (not multiple-pass layout).
> 
> I’m not sure what you mean about combining with CSS Exclusions. Yes, when
> you combine features complexity goes up. I don’t see anything special
> about the combination of regions and exclusions.
> 
>> While things with
>> unpredictable performance characteristics might make sense as a
>> high-level features, I think it's very bad for something we want to
>> make a primitive.  We should be designing primitives that have
>> behaviors that we know how to make fast, so that people who want to
>> build on top of them can have confidence in their performance
>> characteristics and confidence that what they're building will
>> perform acceptably.
>> 
>> Treating performance as a secondary concern, one that can always be
>> sacrificed for correct behavior, is not acceptable.  Designing
>> features that can be fast, and predictably fast, should be an
>> explicit goal of the working group's design process, and we should
>> sometimes sacrifice other goals to achieve it.
> 
> I agree, which is why regions uses one-pass layout in almost all cases,
> and only devolves to two-pass layout when absolutely necessary. We
> sacrificed further refinements in favor of finishing layout as quickly as
> possible.
> 
> 
>> I think this is even more important for primitives; primitives
>> should be things with easily understandable performance
>> characteristics so that we can understand the performance
>> characteristics of the things we build on top of them.  Saying that
>> the performance issues can go away "as an optimization" in most of
>> the important cases is not good enough.>
> 
> The optimizations we mention are about taking out some of the steps on the
> way through one-pass layout.
> 
> You may be thinking the whole thing is too complex because this is the
> first time CSS has actually described how fragmentation works in rigorous
> terms. Put more simply, section 7 says you need to:
> 
> 1. Find the fragment containers and their sizing constraints
> 2. Given those constraints, lay out the content into fragments
> 
> If the fragments match the container sizes you got from step 1, you’re
> done. If step 2 caused any of the fragment containers to resize, then you
> go to step 3:
> 
> 3. Take the current fragment container sizes and lay out the content into
> them
> 
> If you see improvements that can be made, I’d really like to see them.
> Lacking that, I do think this is the simplest way to actually do
> fragmentation into variably-sized containers.

Is there any reason these steps involved should/could be any different when flowing content into a bunch of variably-sized overflow fragments, some of which have size constraints that require an additional pass?

Or, alternatively, if David has an algorithm in mind that makes the layout of chains of variable-size overflow fragments really fast, is there any reason the same algorithm couldn't be used to lay out regions?

Received on Thursday, 23 January 2014 15:45:33 UTC