Re: A couple of questions about the new order

Owen Taylor wrote:

>On Tue, 2003-11-25 at 16:01, Robert O'Callahan wrote:
>  
>
>>I maintain the rendering manager for Mozilla. I've a couple of questions 
>>about how things could work in the new world.
>>
>>Will we be able to use XDamage, XComposite etc (maybe XTest?) to fully 
>>encapsulate legacy plugins that manage their own X windows? We need to 
>>be able to stop them from rendering directly to the screen and directly 
>>receiving input, capture their rendering into our own arbitrary 
>>offscreen buffer, and poke them with input events when we feel like it.
>>    
>>
>
>There's nothing in the new extensions for handling input, anything
>there would have to be added separately.
>  
>
It would be nice to have :-).

>>We have a single logical canvas that for annoying reasons has to be 
>>projected on top of a whole stack of GTK windows. 
>>    
>>
>
>Mozilla didn't use a big stack of GTK windows (widgets, actually)
>last I checked. It may use a big stack of GDK windows (correspond
>to X windows), but that's entirely an internal Mozilla thing.
>  
>
Sorry, I meant GDK windows.

>>We want to be able to 
>>combine updates to this whole tree of X windows, geometry changes to 
>>those windows, and scrolling, all into one visually atomic operation. 
>>How can this be done and how would it interact with XComposite? Here's a 
>>sort of plan:
>>1) Create an offscreen buffer for our logical canvas
>>2) Copy some of our old pixels into this buffer from XComposite's 
>>backing store (when scrolling is happening)
>>3) Draw new pixels into the buffer
>>4) Change geometry of X child windows
>>5) Atomically update and validate most (but maybe not all, e.g., 
>>non-encapsulated plugins) child X windows with appropriate regions of 
>>this buffer
>>Will we be able to do this? Would the result be optimal?
>>    
>>
>
>Having a window act as a compositing manager for its children is
>certainly one of the exciting possibilities of the Composite 
>extension.
>
That's not what I meant, sorry...

>Something along the lines of what you sketch should
>be possible, though I don't really understand what you mean
>by "atomically update and validate"
>  
>
In step 5 we need to update a set of X windows as one visually atomic 
operation. We also want these updates to obviate any updates generated 
by the geometry changes. (I believe GTK2 already supports this latter 
part using some hackery.)

>>I don't see any way to avoid having separate application and XComposite 
>>backing buffers while the application is rendering. If you have just one 
>>buffer then you have a problem if XComposite wants to recompose the 
>>screen while the app is in the middle of rendering.
>>    
>>
>
>A common trick (DirectFB, OS/X) do it is to simply freeze updating
>while the application is painting to the offscreen buffer. I've
>been told that in OS/X if you do something else that causes a repaint
>(like trigger an expose) while an application is redrawing, it simply
>goes ahead and repaints anyways, with a little temporary inaccurate.
>
>This could be done completely at the CM/Application layer without
>any server extensions.
>  
>
Interesting, but if painting takes a while, that could be very annoying. 
It seems like it would be worth spending a bit more memory to get it right.

Rob