From 1b2b08c5f3a5941151a2f4a8c5da7f214ee979e4 Mon Sep 17 00:00:00 2001
From: Chia-I Wu
EGL_RENDER_BUFFER
In EGL, the color buffer a context should try to render to is decided by the
+binding surface. It should try to render to the front buffer if the binding
+surface has EGL_RENDER_BUFFER
set to
+EGL_SINGLE_BUFFER
; If the same context is later bound to a
+surface with EGL_RENDER_BUFFER
set to
+EGL_BACK_BUFFER
, the context should try to render to the back
+buffer. However, the context is allowed to make the final decision as to which
+color buffer it wants to or is able to render to.
For pbuffer surfaces, the render buffer is always
+EGL_BACK_BUFFER
. And for pixmap surfaces, the render buffer is
+always EGL_SINGLE_BUFFER
. Unlike window surfaces, EGL spec
+requires their EGL_RENDER_BUFFER
values to be honored. As a
+result, a driver should never set EGL_PIXMAP_BIT
or
+EGL_PBUFFER_BIT
bits of a config if the contexts created with the
+config won't be able to honor the EGL_RENDER_BUFFER
of pixmap or
+pbuffer surfaces.
It should also be noted that pixmap and pbuffer surfaces are assumed to be
+single-buffered, in that eglSwapBuffers
has no effect on them. It
+is desirable that a driver allocates a private color buffer for each pbuffer
+surface created. If the window system the driver supports has native pbuffers,
+or if the native pixmaps have more than one color buffers, the driver should
+carefully attach the native color buffers to the EGL surfaces, re-route them if
+required.
There is no defined behavior as to, for example, how
+glDrawBuffer
interacts with EGL_RENDER_BUFFER
. Right
+now, it is desired that the draw buffer in a client API be fixed for pixmap and
+pbuffer surfaces. Therefore, the driver is responsible to guarantee that the
+client API renders to the specified render buffer for pixmap and pbuffer
+surfaces.