[webkit-dev] Page, Frame, FrameView and FrameTree clarification needed

[Adam Roben]

On Jul 16, 2007, at 1:59 AM, Holger Freyther wrote:

> 	-Each Page has one main Frame?

    Yes.

> 	-Each Frame has a FrameView? Is that mandantory or should the  
> FrameView only be created when FrameLoaderClient::makeDocumentView  
> is getting called?

    Yes. In the Windows implementation, a FrameView is created  
immediately after Frame construction (see  
WebFrame::initWithWebFrameView in WebKit/win/WebFrame.cpp).

> 	-Each Frame has a FrameTree containing child frames?

    The FrameTree object is essentially a sub-object of Frame that  
contains all the methods for accessing the tree structure of the Frame.

> 	-Frames not in a (grand)parent-child relationship don't overlap?

    I would imagine that you could have two overlapping sibling  
iframes, but perhaps you're only speaking of HTMLFrameElements.

> 	-The RenderTree defines the z-order of the RenderWidget in a  
> RenderFrame?

    The (Render)Layer tree maintains z-order information for all  
RenderObjects.

> 	-The widget of a RenderFrame is a FrameView?

    Yes.

> I think there are probably two approaches to implement it:
>
> 1.) Have one GdkWindow for the main Frame of the Page
> 	+ Resource friendly
> 	+ z-order would always be right
> 	- Scrolling would need to be manually handled by ScrollView (e.g.  
> similiar to the Qt port)
> 	- Complex handling of coordinates
> 	- Complex to get right at the beginning (clipping, translation of  
> the GraphicsContext)
> 	- Embedding real Platform::Widget will be more tough.
>
> 2.) Have one GdkWindow for each FrameView
> 	+ Easy and understandable
> 	- Need to get passing expose events to children right to have the z- 
> Order.
> 	- Need to make ScrollView::update update the right (outermost) region
> 	- Would only work when we have non-transparent overlapping Frame's  
> (does this apply?)
>
> 3.) What did I miss?
>
> Answers and pointers to manual Frame tests would be appreciated. I'm  
> tempted to go with the 2nd option.

    I think you'll have a much easier time getting things right in the  
end if you go with the first option (one native widget (GdkWindow) per  
Page, not per Frame). Otherwise you'll have lots of trouble getting  
painting to happen in the correct order (imagine an absolutely  
positioned div in the main frame that overlaps a subframe -- the  
subframe needs to paint after everything in the main frame *except*  
for the div).

> PS: Yes, we should get DumpRenderTree working for Gtk+ and should  
> look into validating test results...

    Yes, that would be good :-)

-Adam