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

[Kevin Ollivier]

Hi Adam,

On Jul 16, 2007, at 9:52 AM, Adam Roben wrote:

[snip]

>> 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).

Are there test cases in DumpRenderTree, etc. that can be used to  
explore how well a port handles conditions such as these? I'm  
actually using #2 for wx and so far it's been working quite well, but  
I honestly don't know how it handles some of those cases you  
mentioned, and I'd like to be able to verify that it works (or  
doesn't, as the case may be... ;-).

Thanks,

Kevin

>
>> PS: Yes, we should get DumpRenderTree working for Gtk+ and should  
>> look into validating test results...
>
>    Yes, that would be good :-)
>
> -Adam
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev