Top-most windows

[Keith Packard]

On Fri, 2006-01-06 at 11:52 -0800, Deron Johnson wrote:
> 
> 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	

We will solve this by using RedirectSubwindows and flagging the output
window as un-redirected. The alternative leaves windows receiving bogus
expose events that they may not process correctly (map menu, paint
without waiting for expose will fail))

> Section 6 Disabling the X cursor image			

No, the input redirection will still have the X server believing that
the cursor is in one of the underlying windows. The correct fix here is
to add hide cursor and show cursor requests to XFixes. I haven't quite
settled on what semantics these should have yet (Windows just uses a
global count, which seems fairly harsh).

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

The stacking order isn't all that relevant for event delivery; we're
placing the event redirection agent in charge of the pointer containment
for event processing purposes.

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

Yes, it's a well known concept and already exists within the X server as
well.

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

No, in the compositing world, grabbing the server isn't really that
nasty -- you can't see any changes unless the compositing manager paints
them in any case, so it hardly matters if the compositing manager has
the server grabbed. In fact, you might well get better performance
overall as this will tend to 'batch' other application window updates
when the compositing manager is especially busy.

I agree that grabbing the server is generally an ugly idea, but at least
for now I suggest we give this a try as it *requires no X server
changes*.

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-arch/attachments/20060106/2891411d/attachment-0001.pgp