What about glxCopyContext

[Jon Smirl]

On 5/17/05, Brian Paul <brian.paul at tungstengraphics.com> wrote:
> Matthias Hopf wrote:
> > On May 15, 05 19:24:44 -0600, Brian Paul wrote:
> >
> >>Jon Smirl wrote:
> >>
> >>>Do we need an eglCopyContext()?
> >>
> >>I don't recall ever seeing a GLX application that used glXCopyContext.
> >> Does XGL need it?
> >
> >
> > Not really.
> >
> > 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?

There are two schemes for doing XGL:

1) XGL process is the process that draws. All of the apps use indirect
GL rendering. Apps render to surface which is owned by XGL process.
XGL process then composes these surfaces together.

2) All processes direct draw. XGL server assigns a surface to each
process which it then direct renders into.  The missing mechanism is
how do these surfaces get assigned, and then recovered by the XGL
process to be composed.

-- 
Jon Smirl
jonsmirl at gmail.com