Top-most windows

[Keith Packard]

On Mon, 2006-01-09 at 13:35 -0800, Deron Johnson wrote:
> So, after the recent flurry of e-mail on this topic, where do we
> stand?
> 
> I don't think that the grab/raise/ungrab approach is a viable
> candidate. It places a giant lock around something that shouldn't be
> locked.

There's already a giant lock around the server rendering operations; the
graphics hardware is single threaded, and contexts are expensive to
swap. If the compositing manager really is spending 1/2 the frame time
to repaint the screen, then you only get 1/2 for all other application
drawing; there are no visible changes on the screen until painted by the
compositing manager. I would hope that any reasonable compositing
manager would consume far less of the system resources than this.

> Drawing to root window is not viable either. Switching the root window
> to be double-buffered on-the-fly would require major architectural
> change to OpenGL, and I'm not entirely sure that all extant hardware
> could support it.

I don't know of any hardware reason that would prevent it; it's already
supported today, the only issue is that the fb configuration is fixed by
the default visual. We haven't learned what level of effect making this
configuration changable on-the-fly would have on GLX.

> Reparenting top-level windows to be children of a pseudo-root window
> has proven itself to be an approach fraught with peril. I haven't
> heard of anyone on this list who is in favor of the hacks I had to do
> to get this to work, or who has suggested cleaner ways to work around
> the problems.

Reparenting is wrong, of course. This doesn't rule out a pseudo root
extension, which has already been proven to work with existing X
applications just fine. The issue with the existing pseudo root
extension is more that it requires the compositing manager be started
before all other applications, and creates a separate X connection (:1)
to distinguish between the 'real' and 'pseudo' root connection
information blocks.

> The topmost window seems to me to be the cleanest of the approaches
> mentioned so far but it begs the question as to how general should it
> be and how will window managers deal with that generality.

The topmost window approach has the widest impact on the visible
semantics of the window system. For this reason alone, I will continue
to explore other options with lessor impact on the overall system
semantics.   
 
> I have even considered the idea of using a user-managed screen saver
> (that is, a screen saver that the user draws to) but this would mean
> that LG could not leverage the X screen saver.
> 
> (Are there any other proposals which I have not mentioned in this
> summary?)
> 
> What LG really needs is some way to tell the X server that it is the
> only one who is going to be drawing to the screen and don't let any
> other windows get in the way (except for the X screen
> saver). Something sort of like the DGA extension.  Perhaps trying to
> fit things into a window-like model is too complex because it
> introduces new paradigms that the window manager must deal
> with. Perhaps having a simple concept like "I am the composite
> manager. I rule the screen real estate" is a simpler, more direct
> concept.

We already have a 'I rule the screen real estate mode', it's called
OverrideRedirect rendering to the Root window. We're really trying to
discover some GLX-specific kludge-around here, it's not a general
problem with the current architecture.  With this in mind, fixes to GLX
should be considered more in-scope than general changes to the window
system.

-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/20060109/c7fb8c9f/attachment-0001.pgp