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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
