[Mesa-dev] Do we support front buffer rendering with EGL? Do we want to?

[Chad Versace]

On 05/31/2013 03:01 PM, Paul Berry wrote:

> The EGL 1.4 spec
> leaves some wiggle room about whether front buffer rendering is allowed, to
> accommodate window systems that don't permit front buffer rendering.
> However, since X11 supports front buffer rendering, it seems to me that
> Mesa-EGL-X11 ought to support it.

I suspect that the wiggle room you mention refers to this text:

---- -8<- ----
Some window systems may not allow rendering directly to the front buffer of
a window surface. When such windows are made current to a context, the context
will always have an EGL_RENDER_BUFFER attribute value of EGL_BACK_BUFFER.
 From the client API point of view these surfaces have only a back buffer and no
front buffer, similar to pbuffer rendering (see section 2.2.2). Client APIs which
generally have the ability to switch render target from back to front will not be able
to do so when the window system does not allow this; from the point of view of
the client API the front buffer for such windows does not exist.
---- -8<- ----

When I read this, I think of Android's window system, in which the front buffer truly
does not exist. Historically, X does have front buffers, so I don't think this the
wiggle room clauses in this text apply to X.

> Also, some of us have pipe dreams of a future where Linux desktop apps
> transition over to using EGL instead of GLX.  It seems like supporting
> front buffer rendering via EGL would help encourage that.

If we really wish to deprecate GLX and push applications to use EGL,
then I believe we need to support front-buffer rendering in EGL
lest we break any existing and future GL applications that may rely
on it. However, I've never done a survey of which applications do
front buffer rendering and why, so some may argue that we really shouldn't
care.