Top-most windows

[Deron Johnson]

Soeren Sandmann wrote On 01/06/06 11:28,:

> The right semantics seem to me that manually redirected windows would 
> not clip
> anything. They are not visible on-screen after all.

Not only does the topmost window concept solve the clipping issue but
it also solves a host of other problems that your suggestion does not.
The topmost window concept also solves the following problems:

(Refer to my document "Looking Glass Modifications to Xorg")

Section 4.2 Exposure handling modification		
Section 5 Atomic mapping of top-level ovredir wins	
Section 6 Disabling the X cursor image			
Section 9.2 Emacs bug workaround	

(Refer to my document "A Trip Up the Looking Glass Event Pipeline")

Section 14.1.2 DeliverDeviceEvents

These sections describes hacks I've implemented to work around
various problems. I can't think of any other solution than topmost
windows that solves so many problems at the same time. The key
ingredient is that the window that the composite manager renders
to is a SIBLING of the top-level root window children. Then, as
long as you can guaranteed that this sibling is always on top,
you're golden.

I think that one of the reasons Keith suggested the topmost
window idea is that Windows as a similar concept.

> If that's too hard to implement, then note that a 'topmost' window is 
> not actually
> necessary. The compositing manager only needs the window to be topmost when
> it is actually drawing, ie:
> 
>     grab_server();
>     XRaiseWindow();
>     draw_scene();
>     ungrab_server();
> 
> would be sufficient.

Grabbing the server is very heavy weight. Server grabs should be avoided
unless absolutely necessary. We need a solution that doesn't involve
grabbing the server.