RenderLayer code

[Lars Knoll]

> On Thursday, January 30, 2003, at 11:26 AM, Lars Knoll wrote:
> > Talking about memory usage: There are a few other places I noticed you
> > using
> > too much memory. The booleans  quirksmarginTop/Bottom in RenderFlow
> > should
> > for example be added to the bitfield a few lines above. Saves 8 bytes
> > for
> > every renderflow.
>
> Thanks.  I'll make that fix.
>
> Another idea I had for saving more memory is to split RenderFlow into
> RenderBlock and RenderInline.  Then the inline-specific and
> block-specific variables could move into the derived classes.
> RenderFlow could be kept as a common base class.

I had the same idea. The main reason for them being the same class was that 
inlines could merge into blocks. This is unneeded now with your continuation 
code. I am all for it, as it should clean up things quite a bit. 

I am not sure if you would want to do that before your 1.0 release, but if 
yes, I think we should somehow try to work on a common code base here.

> > Another issue I am currently wondering about is if we could avoid the
> > 4 shorts
> > used for margin calculations in renderflow. They are purely
> > intermediate
> > values, and could maybe get passed along in the layout() calls.
>
> I believe this is difficult to do.  The problem is incremental layout..
>   Unless you are prepared to relayout everything, you won't know the
> correct maximal margin values without having them cached.  Gecko
> actually implemented margin collapsing by passing state through the
> Reflow() method, and they have tons of bugs with incremental layout
> because of it.

Ok. In this case it might be better to store them. If we split block and 
inline objects, we will save more memory than we loose here.

Lars