What is the status of EGL_MESA_screen_surface?

[Paul Ramsey]

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

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

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

-- 
Paul Ramsey
Sun Microsystems, Inc.
877-242-2631