What is the status of EGL_MESA_screen_surface?

[Brian Paul]

Paul Ramsey wrote:
>>It hasn't been circulated in Khronos yet, but probably should be.
> 
> 
> Yeah, I'm curious to see if they'll support EGL going in this direction.
> 
> 
>>Don't think of it as just a basis for a window system, but as a 
>>cross-platform interface for "full-screen" OpenGL.
>>
>>There's a lot of people out there who want to use OpenGL but don't 
>>want/need an X server.  For example, in embedded/vehicle applications. 
>>  In the past we devised a "mini GLX" API that used fbdev to use the 
>>DRI drivers outside of X.
>>
>>The proposed EGL extension approach is much cleaner and has many 
>>possible applications.  Running an X server on top of it is just one 
>>example (an especially interesting one, but that's another topic).
> 
> 
> I'm totally on board with not requiring a window system to do OpenGL. We have
> our own need for this at Sun. Changing the name of these functions and making
> small adjustments to the how the functions are integrated doesn't discard this
> capability, it just separates display management from OpenGL rendering.
> 
> When developing from a single point of view, it's always "cleaner" to have one
> giant API than to have separate ones, but modularity works for us in the long
> run. For instance, I can easily imagine that there could be a need to access a
> simple frame buffer which doesn't implement 3D graphics. As an extension to EGL
> there really is no way to provide a 2D only frame buffer without creating yet
> another API which covers the same territory.

EGL 1.2 supports multiple rendering APIs in addition to OpenGL 
(OpenVG, for example, is included in the spec).  By adding a new token 
or two, eglBindAPI() can be used to choose interfaces other than OpenGL.

As for a "2D" framebuffer, you can just choose an EGL config that 
doesn't have z/stencil, is single-buffered, etc.


>>The idea is to provide a complete interface so the developer doesn't 
>>have to be concerned with any other lower-level native environment. 
>>The implementation of EGL_MESA_screen_surface (and EGL itself) might 
>>of course tie into a lower-level interface such as fbdev, or it might 
>>program the hardware directly.  In any case, the EGL application 
>>developer doesn't have to care.
> 
> 
> Having all of the functions have "egl" at the first three letters of the name
> doesn't make it more complete. It just puts Khronos into the business of
> designing minimalist window systems.

Khronos doesn't have to do anything.  It'd be nice if this were an 
"EXT" extension, but we can go ahead as a "MESA" vendor extension.

Again, this isn't a minimalist window system.

If I were looking to design a screen/mode/display API but had no 
interest in OpenGL I'd probably go the non-EGL route.  But that's not 
what we want to do.


>>I guess one could do that, but I think it's simpler to just have a new 
>>sub-type of drawing surface.  Also, we don't have to worry if all the 
>>EGL window surface properties/semantics apply to screen surfaces, and 
>>vice versa.
> 
> 
> As far as EGL is concerned a ScreenSurface as described in this spec already has
> all of the semantics of a window. The window just happens to be full screen.

Something about that just doesn't feel right to me.  An EGL window 
surface is associated with a native window system's window.  But there 
won't be a native window system at all.

-Brian