Re: The big layout debate v1

On Thu, 2004-04-01 at 02:33 -0800, Adam Megacz wrote:
> Nice work, Charlie!  I largely agree that your proposal is much better
> than what we're doing now.  I just need to figure out if it's going to
> be computationally prohibitive, but I suspect not.

It isn't computationally prohibitive.  I've already implemented.  It is
not any slower overall than the current Box.java resize_children(),
although I did speed up the handing out of slack which might account for
a slight slowdown in other parts of the function.

The main slowing factors for the core are currently:

 o  Copious calling of repack() - there are large number of repack()
    calls, more than is necessary, e.g. on mouseover repack() is called

 o  Dumb repacking - repack() is currently dumb, it just repacks the
    box regardless of whether it is necessary.  We need to make repack()
    on do some work if:
       *  A child has been added
       *  A child has changed a span attribute
       *  A child has a changed contentsize
       *  Updated rows or cols
  
You can pull my patches from charlietech.com/darcs/ibex or just try the
jar to compare: www.charlietech.com/tmp/current.jar or latest.jar

(latest.jar contains a repack rewrite which is slightly faster, I think)

> > Each column's minimum width is set to the maximum minwidth of all the
> > boxes in that column.
> > Each column's maximum width is set to the maximum maxwidth of all the
> > boxes in that column, but no smaller than the column's minimum width.
> 
> I assume that if the resulting minwidth is bigger than the maxwidth,
> then you increase the maxwidth to be equal to the minwidth?

In my patch the maxwidth of a column is never less than the minwidth,
something along the lines of (where i = child.col):

colMaxWidth[i] = max(colMaxWidth[i], max(colWidth[i], child.maxwidth));

> Hrm, this is a really interesting idea.  But it's still not specific
> enough... in particular, let's say we have three columns each with
> minwidth=20 (as a result of other boxes).  Then there's a box spanning
> all of them which has minwidth=70.  Do we split the "extra 10 pixels"
> evenly across the columns?

At the moment, this is the behaviour of my patch.  I think this is also
how HTML tables behave.

We could either do this or perhaps add the extra pixels to the end
column, but I think the above makes more sense.  Also, if people are
really that bothered about maintaining the slimness of their columns
whilst having a colspan with a minwidth, they'll throw in an additional
unmaxed box into the column they want the slack in, or even an extra
column of unmaxed boxes to take up the slack.

> > If possible, the sum of the columns' widths will be equal to the
> > parent width.  The instances where this might not be possible are if
> > the sum of the columns' maxwidths is less than the parent width or
> > if the sum of the columns' minwidths is greater than the parent
> > width.
> 
> If this is not possible, I assume you align the columns according to
> the parent's align attribute?  BTW, this is why I introduced the
> concept of "cells"; it's merely there to make describing this
> phenomenon easier.

Currently what happens (and my patches do not affect this) is that if
the result is smaller than the parent box, the grid remains tightly
packed together and the resultant image is aligned according to the
parents align attribute.  Is that what you mean?

> > Specifically, the current Placing spec causes mass clipping of boxes to
> > force them into cells which really doesn't work right.
> 
> Er, no, actually the current implementation is just broken ;)

As I was trying to tell you at H3. ;)

> > insisted it was right during H3.  The problem is the introduction of the
> > concept of cells confuses matters.
> 
> Oh, okay, now I see what you mean about cells.  Yeah, I agree.
-- 
- Charlie

Charles Goodwin <[email protected]>
Online @ http://www.charlietech.com