Top-most windows

[Keith Packard]

On Tue, 2006-01-10 at 09:37 -0800, Deron Johnson wrote:

> Another problem with constantly raising the window is that you
> are constantly thrashing doing DID preparation on all of the windows.
> In addition, you've got normal X windows continually popping above
> the compositing window and they will be visible as artifacts.
> The grab/raise/ungrab approach is a complete non-starter.

There are no visible artifacts -- the windows are redirected and hence
do not affect the visible presentation on the screen. The only effect is
caused by clipping during the update process which could (when the back
buffer is also affected by clipping) cause portions of the resulting
frame to be undrawn. The compositing manager can easily detect when this
happens and redraw the affected area; the usual expose handling will
already take care of this correctly.

And, of course DID issues aren't relevant to most hardware.

> But it still doesn't solve the DID rendering problem. Even if you
> have a double-buffered pseudo-root its children (who are typically
> single buffered) will still be rendered with a different DID than
> than the pseudo-root parent. This results in weird-looking "holes"
> on the screen.

I don't think you understand how a pseudo root would work.
 
> I think you mean "IncludeInferiors rendering," don't you? Unfortunately,
> this only "rules the screen" spatially. It doesn't rule the screen
> visually. The DIDs of the child windows are still painted, resulting in
> visual artifacts.

Yes, I have no recent experience with DID-based hardware and so tend to
ignore their effect. Are there relevant COTS chips which still include
DID?

-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/20060110/468610dc/attachment-0003.pgp