Top-most windows

[Deron Johnson]

Note: I was not suggesting that we solve these problems in the
way I wrote in the document. I was merely using the document as
a way of pointing out all of the problems associated with making
the composited windows children of the window the composite
manager is rendering to.

Also note that we don't need to add anything to XFIXES to
disable the cursor issue because this falls out of the topmost
window concept--you just assign an invisible cursor to the
topmost window.

Keith Packard wrote On 01/06/06 17:23,:
> 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
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> xorg-arch mailing list
> xorg-arch at lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-arch