Top-most windows

[Deron Johnson]

My understanding was that the reason why we did the composite wrapper
was so that DDXs had some time to "catch up." I thought that we were
doing it so that we could be compatible with existing DDXs.

So the issue is: should we require DID-using DDXs to change in order to
properly work with composite or are we going to provide some sort of
server tool/behavior to ease the transition? Just as we introduced a
new function which the DDX uses to tell composite whether or not it
needs the wrapper perhaps we can introduce a similar function which the
DDX can use to tell the server that it handles DIDs properly.

Keith Packard wrote On 01/18/06 18:30,:
> On Wed, 2006-01-18 at 14:45 -0800, Deron Johnson wrote:
> 
> 
>>I'm not convinced that the Nvidia DDX is the one that is busted. There
>>are no specific semantics in the DDX porting layer that specify when
>>DID painting should and should not occur. The Nvidia DDX is doing
>>nothing wrong when it is painting DIDs in the ValidateTree and
>>HandleExposures functions.
> 
> 
> Sure, but PaintWindowBackground happens to be the 'obvious' place as it
> is always presented with a minimal region needed to adjust the DID area.
>   
> 
>>Could you remind me what EXA is and how it will fix this problem? I
>>haven't been following the EXA stuff very closely. Is EXA going into the
>>proprietary ATI drivers, or just the DRI drivers?
> 
> 
> The CompositeWrapper code was written because XAA (and other drivers) 
> didn't use the macros and functions provided by the DIX layer to access
> the correct pixmap for each window. Instead, they assume that all
> windows live in the screen pixmap. This breaks Composite which places
> windows in separate pixmaps. To fix this, CompositeWrapper presents the
> underlying DDX with the pixmaps themselves, rendering commands are
> suitably adjusted to offset and clip to the window location within the
> pixmap.
> 
> It's a horrible kludge, but needed by XAA-based and the closed source
> drivers.
> 
> EXA, on the other hand, works with Composite without needing the
> CompositeWrapper layer. This eliminates all kinds of nasty
> window-painting related issues. As CompositeWrapper hides windows from
> the driver, PaintWindowBackground is not visible to the driver any
> longer, replaced with the usual painting operations involving pixmaps
> and GCs.
> 
> 
>>If one had access to the DDX code one could modify the following DDX
>>functions to not paint DIDs for a composite-redirected window:
>>ValidateTree, HandleExposures, PaintWindowBackground, PaintWindowBorder.
> 
> 
> Actually, I think you need deal only with CopyWindow and
> PaintWindowBackground/Border, and in those cases, the only check needed
> would be to paint DIDs only when the window pixmap was the same as the
> screen pixmap. No Composite-knowledgable code should be needed at all.
>