Graphics Reference
In-Depth Information
height of the surface in pixels; whether the surface uses color, depth, and
stencil buffers; and the bit depths of these buffers.
By default, OpenGL ES uses the window system-provided framebuffer as
the drawing surface. If the application is drawing only to an on-screen
surface, the window system-provided framebuffer is usually sufficient.
However, many applications need to render to a texture, and for this
purpose using the window system-provided framebuffer as your drawing
surface is usually not an ideal option. Examples of where the render-to-
texture approach is useful are shadow mapping, dynamic reflections and
environment mapping, multipass techniques for depth-of-field, motion
blur effects, and postprocessing effects.
Applications can use either of two techniques to render to a texture:
• Implement render to texture by drawing to the window system-
provided framebuffer and then copy the appropriate region of the
framebuffer to the texture. This can be implemented using the
glCopyTexImage2D
and
glCopyTexSubImage2D
APIs. As their names
imply, these APIs perform a copy from the framebuffer to the texture
buffer, and this copy operation can often adversely impact performance.
In addition, this approach works only if the dimensions of the texture
are less than or equal to the dimensions of the framebuffer.
• Implement render to texture by using a pbuffer that is attached
to a texture. We know that a window system-provided surface
must be attached to a rendering context. This can be inefficient
on some implementations that require separate contexts for each
pbuffer and window surface. Additionally, switching between
window system-provided drawables can sometimes require the
implementation to flush all previous rendering prior to the switch.
This can introduce expensive “bubbles” (idling the GPU) into the
rendering pipeline. On such systems, our recommendation is to
avoid using pbuffers to render to textures because of the overhead
associated with context- and window system-provided drawable
switching.
Neither of these two methods is ideal for rendering to a texture or
other off-screen surface. What is needed instead are APIs that allow
applications to directly render to a texture or the ability to create an
off-screen surface within the OpenGL ES API and use it as a rendering
target. Framebuffer objects and renderbuffer objects allow applications
to do exactly this, without requiring additional rendering contexts to
be created. As a consequence, we no longer have to worry about the
overhead of a context and drawable switch that can occur when using
