Re: [css3-box] Issue with the current shrink to fit algorithm

On 10/28/10 10:52 AM, Giuseppe Bilotta wrote:
>> Determining the latter involves doing a full layout on all the descendants,
>> no? And if you have nested shrink-wrap containers, doing that a number of
>> times that's exponential in the nesting depth?
>
> And how is that different from the first step of the current
> algorithm? Don't you need to do a full layout of all the descendants

No, you just need to apply some basic heuristics (look at the computed 
styles, plus the simple shrink-wrap algorithm) for them.

> The only difference I see is that in the algorithm currently used, the
> layout is done assuming max-width: none, whereas in my case it would
> be done assuming max-width: available-width. Or am I missing
> something?

I think you are missing something.

To make this concrete, for a block box in Gecko the width determination 
when shrink-wrapping (which is what needs to be done on all descendants 
in a shrink-wrap situation is 
http://hg.mozilla.org/mozilla-central/file/882525a98119/layout/generic/nsBlockFrame.cpp#l762 
going through line 837.  It does call some other code; total estimated 
amount of code involved including all the functions this calls is < 1000 
lines.

The code for doing an actual layout is 
http://hg.mozilla.org/mozilla-central/file/882525a98119/layout/generic/nsBlockFrame.cpp#l1770 
going through line 2370.  Total estimated amount of code involves is 
tens of thousands of lines.

> There's an additional bonus here, too, since most of the results of
> the layout during the "preferred width not greater than the available
> width" can actually be directly used, whereas with the current
> specification, after laying out the inner boxes assuming no max-width
> you'd have to re-layout them assuming the shrinked width.

You're making the assumption that actual layout happens during the 
shrink-wrap pass.  The point is, it doesn't.  Some heuristics are used 
to approximate what layout would look like and avoid all the complexity 
of actual layout.

>> and _still_ gives "incorrect" results in many cases.  The set of cases where
>> this behavior helps is very small...
>
> I would like to know of some of the cases where my proposed algorithm
> would give "incorrect" result

For Gecko's old implementation, which basically used your proposal, that 
would be most of the crossed-out items in the "Bug 300030 blocks" 
section of 
https://bugzilla.mozilla.org/showdependencytree.cgi?id=300030&hide_resolved=0

-Boris

Received on Thursday, 28 October 2010 15:04:53 UTC