Graphics Reference
In-Depth Information
Note:
The width and height of the off-screen renderbuffers do not have to
be a power of 2.
Here, we discuss some performance tips that developers should carefully
consider when using framebuffer objects:
• Avoid frequent switching between rendering to the window system-
provided framebuffer and rendering to framebuffer objects. This is an
issue for handheld OpenGL ES 3.0 implementations, as many of these
implementations use a tile-based rendering architecture. With a tile-based
rendering architecture, dedicated internal memory is used to store the
color, depth, and stencil values for a tile (i.e., region) of the framebuffer.
The internal memory is used as it is much more efficient in terms of
power utilization, and it has better memory latency and bandwidth
compared with going to external memory. After rendering to a tile is
completed, the tile is written out to device (or system) memory. Every
time you switch from one rendering target to another, the appropriate
texture and renderbuffer attachments will need to be rendered, saved,
and restored. This can become quite expensive. The best method would
be to render to the appropriate framebuffers in the scene first, and
then render to the window system-provided framebuffer, followed by
execution of the
eglSwapBuffers
command to swap the display buffer.
• Don't create and destroy framebuffer and renderbuffer objects (or any
other large data objects for that matter) per frame.
• Try to avoid modifying textures (using
glTexImage2D
,
glTexSubImage2D
,
glCopyTeximage2D
, and so on) that are
attachments to framebuffer objects used as rendering targets.
• Set the
pixels
argument in
glTexImage2D
and
glTexImage3D
to
NULL
if the entire texture image will be rendered, as the original data
will not be used anyway. Use
glInvalidateFramebuffer
to clear the
texture image before drawing to the texture if you expect the image to
have any predefined pixel values in it.
• Share depth and stencil renderbuffers as attachments used by
framebuffer objects wherever possible to keep the memory footprint
requirement to a minimum. We recognize that this recommendation
has limited use, as the width and height of these buffers have to be
the same. In a future version of OpenGL ES, the rule that the width
and height of various attachments of a framebuffer object must be
equal might be relaxed, making sharing easier.
