implement window surface

[Adam Jackson]

On Wednesday 18 May 2005 14:00, Jon Smirl wrote:
> On 5/18/05, Adam Jackson <ajax at nwnk.net> wrote:
> > Either that, or don't.  My mental model of Xegl was that all X rendering
> > surfaces would be textures internally, and the server's default
> > composition code (equivalent to X without xcompmgr) would apply them to
> > quads that you draw into the screen surface.  That's exactly the existing
> > model that Xglx uses, where offscreen buffers are composed into a GLX
> > window as textured quads.
>
> That's all correct, but you are assuming we only run XGL on the stack.
> What if people want to run the normal Xserver or miniglx, etc?

No one wants miniglx.  The whole point of extending EGL is to kill off 
miniglx.  And the normal X server doesn't make use of the EGL stack at all.

For the EGL driver that translates to GLX, Windows are exactly like Screens, 
except the client has already created them and Screens have much more state.  
They both map to glXCreateWindow internally.

I suppose I could see the argument that there should be something like:

NativeWindowType eglCreateNativeWindowXXX(Display, EGLConfig);
NativePixmapType eglCreateNativePixmapXXX(Display, EGLConfig);

which would allow you to write an EGL app that was wholly independent of the 
native window system (no #ifdef WIN32 etc).  

> Alternatively what if XGL doesn't have room for all of the offscreen
> pbuffers and wants to make some windows direct draw onto the screen
> surface?

In that case you'll want to migrate the buffer contents out of card memory 
anyway, won't you?  I'm not opposed to short-circuiting the rendering path in 
that case, but you still need a way to create the Window handle that you feed 
to CreateWindowSurface.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dri-egl/attachments/20050518/9c5e5c21/attachment.pgp