What about glxCopyContext

[Matthias Hopf]

> >We need a mechanism for sharing texture data between different
> >*processes*. As the implications and exact requirements for that are not
> >completely clear so far, we decided to delay this until Xgl matured a
> >bit. Then we'll come up with a proposal for another extension.
> 
> I guess I'm not fully aware of the issues yet.  In terms of 
> *processes* there's:
> 
> 1. The EGL layer/driver + XGL server + compositor
> 2. The OpenGL/Xlib application(s)
> 
> Right?  Or is the compositor in a different process?

Yes it is. It typically would be the window manager, though it can be a
different process (and actually usually is at the moment, because AFAIK
no window manager with embedded compositing has been released yet).

So we have
a) The user programm
b) The Xgl server
c) The composite manager

If not using a compositor, we still need texture sharing for supporting
direct rendering (the Xgl server would serve as some kind of composite
manager here).

If using a composite manager we have to share window output from the Xgl
server to the composite manager, which will use direct rendering for
drawing onto the screen. And, of course, from direct rendering clients
to the composite manager as well.

If the composite manager used native X calls or indirect rendering for
drawing, the data would remain in the Xgl server for regular X window
output IIRC, but the more interesting managers would like to use direct
rendering.


David, I'm sure I forgot something else relevant here, so feel free to
correct me ;)

Matthias

-- 
Matthias Hopf <mhopf at suse.de>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat at mshopf.de
Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de