Game Development Reference
animated cartoon on TV. Other common words to describe these cycles are refresh,
iteration, or render-call.
When we perform these tasks, the graphics system spends most of its time handling
the second task: drawing the world's objects onto the canvas. When an object is
rendered the graphics system picks the corresponding pixel in the canvas and sets
the color of the object there.
This canvas is typically referred to as a buffer. Whenever lots of unique values
of a common data type are stored together (in this case a unique color value for
each pixel), we usually refer to it as a buffer.
When the display system is ready to draw the next frame, it grabs the current buffer
from the video memory (which could be in a dedicated GPU or elsewhere) and cop-
ies it for us to be seen on the screen. The buffer is then cleared and the process
But, what happens if the graphics card has not finished rendering all of the objects
before the screen grabs the buffer? If the two processes are not synchronized, it
would result in rendering of partial frames which would look very obvious to the hu-
man eye and ruin the illusion we're trying to create.
To solve this problem, we will use two buffers instead of one; this is called double-
buffering . At any moment, one buffer is being displayed (known as the frontbuffer )
while the other is being drawn to (known as the backbuffer ). When we've finished
drawing onto the backbuffer, we swap the buffers around so that the second is being
displayed, while we draw onto the first. We repeat this process over and over again
to ensure that we never draw onto the same buffer that we're displaying. This results
in a more consistent scene without the graphical glitches.