EGL_MESA_screen_surface version 4

[Jon Smirl]

On Thu, 24 Mar 2005 10:11:17 -0800, Ian Romanick <idr at us.ibm.com> wrote:
> The thing to take home here is the FBOs live in the GL impelementation,
> but windows, pixmaps, and pbuffers are part of the window-system (e.g.,
> WGL, GLX, EGL, etc.).  Because of that, they can't really be managed in
> the same way.

XGL is completely implemented on top of OpenGL+EGL so it doesn't have
native windows or pixmaps. So with XGL is there a way for the same
buffer to:

1) be a render target
2) be a shared texture
3) be a scan out target

#1 is a normal app rendering to an off-screen buffer for compositing
#2 is a buffer from #1 begin composited
#3 is running the normal app full screen in a compatible display mode

On Thu, 24 Mar 2005 10:48:04 -0700, Brian Paul
<brian.paul at tungstengraphics.com> wrote:
> That's implementation-dependent.  In Mesa, I'm working on implementing
> the GL_EXT_framebuffer_object extension.  Within core Mesa both window
> system-created surfaces and user-created framebuffer objects will use
> the same code and types.  The DRI drivers will basically use the new
> gl_renderbuffer and gl_framebuffer types as base classes from which
> they can derive window/pbuffer/etc surfaces.

why is there a distinction between gl_renderbuffer and gl_framebuffer?

-- 
Jon Smirl
jonsmirl at gmail.com