What is the status of EGL_MESA_screen_surface?
brian.paul at tungstengraphics.com
Fri Feb 24 07:06:39 PST 2006
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
> 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.
More information about the dri-egl