RenderLayer code

David Hyatt hyatt@apple.com
Fri, 31 Jan 2003 02:19:29 -0800


On Friday, January 31, 2003, at 01:30 AM, Lars Knoll wrote:

>
>> On Friday, January 31, 2003, at 01:07 AM, Lars Knoll wrote:
>>> I still don't pass test 4 however (see attached screenshot). I think
>>> your code
>>> flattening the ztree does not honour document order when zindeces are
>>> equal.
>>
>> I pass this test.  Something else must be missing...
>
> As I said, the tree you build has no information about document order. 
> I could
> imagine something going wrong in the sorting, but I'll check.

In the newest diff I gave you, the layers preserve document order (in 
their layer tree).  There were bugs with that where I was always just 
appending layers to the end of their child lists.  Now you can even 
dynamically position elements and new layers will appear and be 
inserted into the correct place in the document.

>>> I thought about adding a RenderLayer *nextToPaint pointer to the 
>>> layers
>>> themselves. Like that one would not need an extra list. If a layer 
>>> gets
>>> inserted or removed, the paint order can be recalculated, but the
>>> paint()
>>> method should not need to do this.
>>
>> Note that the ztree construction prunes out layers that don't 
>> intersect
>> your dirty rect, so the list can be different depending on the dirty
>> rect.
>
> We don't do that any other place in the rendering tree. You usually 
> have a
> handful of layers, so I don't see why we can't calculate the complete 
> order
> over the whole document and do the clipping out when painting, similar 
> to how
> we do it in all the paint methods of the different render objects.
>
> IMO it has to be faster, since you have to iterate over all RenderLayer
> objects with every paint() call anyways (now to create the tree, then 
> to
> check if they have to be painted).
>

Yeah, I think you're right.  Let me play around with the code a bit.  
I'll look into making that change and send you a new render_layer.cpp 
file.