EGL_MESA_screen_surface version 4

Brian Paul brian.paul at tungstengraphics.com
Thu Mar 24 09:48:04 PST 2005


Jon Smirl wrote:
> On Wed, 23 Mar 2005 19:24:59 -0700, Brian Paul
> <brian.paul at tungstengraphics.com> wrote:
> 
>>>In the composited desktop model all top level window get their own
>>>surface then the desktop composits them into a single image. Now let's
>>>assume these top level windows are compatible with monitor modes. If
>>>all surfaces are created equal I should be able to transparently make
>>>each top level window full screen and rotate through them.
>>
>>I think that assumption is a bit optimistic.  Top-level windows might
>>very well be stored as textures (perhaps stored in a format that can't
>>be directly scanned out), or pbuffers, or FB objects.  I wonder if
>>Dave Reveman has a preference?
> 
> 
> He wants FB objects.
> 
> 
>>But if top-level windows could be directly scanned out, that could be
>>cool.
>>
>>I guess the key thing about eglCreateScreenSurfaceMESA() is the fact
>>that you're asserting that you want to create a surface especially for
>>scan-out.  I guess you could pass a new flag to
>>eglCreateWindow/Pixmap/PbufferSurface() to indicate that intention,
>>but that feels like a hack to me.
> 
> 
> I thought the whole point of FB objects was to get rid of the
> distinction between window/pixmap/pbuffer. Could the base object
> always be an FBO and window/pixmap/pbuffer are then derived off from
> the FBO?

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.

Other non-Mesa implementations could do things completely differently 
so there's no guarantee of any tangible relationship between FB 
objects and EGL surfaces.

The point of FB objects was to support render-to-texture and provide a 
platform-independent version of pbuffers.  They don't necessarily 
replace window/pixmap/pbuffer surfaces.

I could try to quickly summarize the different kinds of EGL surfaces:

Window surfaces - correspond to windows created by the window system. 
  The user can change their size/visiblity at any time.  The contents 
of windows may be undefined when not fully visible.  EGL windows may 
be rendered into by both OpenGL(ES) or the native window system.

Pixmap surfaces - correspond to server-side off-screen drawing 
surfaces like X's Pixmaps.  Contents are never lost.  EGL pixmaps may 
be rendered into by both OpenGL(ES) or the native window system.  For 
various reasons, hardware-accelerated 3D rendering to Pixmaps never 
materialized in GLX.  So pbuffers were invented.

Pbuffer surfaces - intended for off-screen accelerated 3D rendering by 
OpenGL(ES) only, not the native window system.

-Brian


More information about the dri-egl mailing list