Top-most windows

[Keith Packard]

On Wed, 2006-01-11 at 13:06 -0800, Deron Johnson wrote:
> Keith Packard wrote On 01/10/06 17:04,:
> > On Tue, 2006-01-10 at 09:41 -0800, Deron Johnson wrote:
> >
> > Given the existance of GLX APIs based on FBConfigs, and the potential to
> > additional modify GLX to enable IncludeInferiors rendering, it seems to
> > me that all of our discussions should now be focused on mitigating the
> > effect on a GL-based compositing manager in the short term. 
> 
> I'm not particularly enamored of this approach because I see it as
> taking a long time to come to fruition. 

As I said, this approach can be a part of the larger rearchitecture
necessary to make GL compositing managers possible for Mesa based
drivers. We're well over six months before that's viable in any case.
 
> There are many drivers which
> will have to be upgraded and many people and companies from which we
> will need buy in. I can see this process easily taking 6 months or more
> and even then there will always be some residual devices for which
> support is not provided or is late in coming. In my mind, relying on
> other people and processes to make the composite extension truly usable
> is not a particularly agile strategy.

It's not 'other people', the people doing DRI/Mesa are part of our clan
and are actively working on this right now. We can help them even.

>  Keep in mind that Windows Vista
> will be shipped with these capabilities in the latter half of this year.

The topmost approach doesn't fundementally affect our ability to ship
something today, it only presents a very modest invisible impact on the
implementation. That seems like a minor cost compared to the long term
expense of retaining unnecessary capabilities within X.

> In the meantime people who build 3D window systems will have to continue
> to hack their own copy of Xorg, and will probably need these hacks
> indefinitely in order to support those devices who don't yet support
> the GL mods.

No changes in Xorg are required; we already have presented a workable
architecture which an existing compositing manager has demonstrated.
 
> But if you are firm in wanting to pursue this approach then we will
> still need a solution to the DID rendering problem.

Yes, your DID implementation will need DID drawing fixed for Redirected
windows. That's independent of this issue as any redirection will cause
issues given the defined semantics of the composite extension.

>  And we will also
> need an effective way of disabling the display of all X cursors (even
> grab cursors).

Yes, we've already discussed a mechanism that disables the presentation
of the cursor without destroying the cursor image information. I've
suggested a few times that we should write an
XFixesHideCursor/XFixesShowCursor that affects the presentation of the
cursor within an entire window hierarchy.

> I see no reason to artificially couple this feature with the feature
> of making GL render to off-screen buffers.

It's not an artifice; the reality is that Mesa is not ready today to be
used in the architecture you're proposing. We cannot composite the
output of regular 3D applications into the scene because we cannot
redirect those windows at all. Plus, we have no way to avoid an
expensive fetch/store operation on all window contents as Mesa doesn't
allow us to reference X pixmaps as GL textures directly.

You're already building a kludge tower that doesn't reflect our desired
architecture; one more very minor kludge seems mild by comparison to
these other expenses.

-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/20060112/d31a0dbd/attachment-0002.pgp