EGL_MESA_screen_surface version 4

[Brian Paul]

Jon Smirl wrote:
> 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

Well, EGL does have a render-to-texture feature (section 3.6 of the spec).

If the hardware supports it, I believe extended EGL would allow 1+2+3.


> 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?

In a nutshell, a renderbuffer is either a stencil buffer, a depth 
buffer or color (RGBA) buffer while a framebuffer is a collection of 
renderbuffers (such as 2 color buffers, plus depth buffer, plus 
stencil buffer).  It's all explained in the GL_framebuffer_object 
extension.

-Brian