As we said, double buffering works by using two framebuffers so that we are never setting pixels on the same buffer that is being used for the display. The framebuffer that is currently being displayed is called the front buffer or primary buffer, and the framebuffer that we are drawing to is called the back buffer or secondary buffer.
When drawing is completed on the back buffer, the buffers are swapped so that the back buffer is now the front buffer and the front buffer is now the back buffer. Of course, the buffers themselves are not swapped. Instead, pointers to the buffers are swapped. The monitor has a pointer to one buffer and is currently reading it. The graphics card has a pointer to another buffer that it uses for all draw operations. This pointer swap, or page flipping as it is sometimes called, is much faster than copying data from the back buffer to the front buffer:
As you can see in the next two images, the display can read the front buffer while the graphics processing unit or GPU draws to the back buffer. However, there is nothing about double buffering that has prevented tearing. We have prevented drawing to the same buffer that is being displayed but, if we swap buffers in the middle of a screen refresh, we will still have tearing. This is an important first step in solving the tearing problem. However, before we solve it, let's talk about what happens when we are out-of-sync with the monitor refresh rate because we are generating too many frames per second:
Imagine the situation in which our game is generating 90 frames per second. This is 30 frames more than we need to achieve 1 frame per refresh. This means we are wasting time creating frames that will never be seen. At 90 frames per second, one third of the frames will never be seen by the player. As you can see in Figure 11.11, every third frame, which is highlighted in green, will be skipped because it falls between two refresh intervals. Even more frames will be skipped if we are updating at 120 fps or more:
At 90 frames per second, every frame takes 1/90th of a second to complete. From the player's perspective, the third frame that gets shown (which is really our fourth frame) has been updated for a total of 1/45th of a second, or double the amount of time. Just like with the movie at 24 fps, this can cause a jittery effect that some players may notice because all objects will appear to have moved twice as far.
When updating this many times per second, these time slices are very small. It is possible that they are so small that they may go unnoticed by the player. The real problem with skipping frames is that our game is doing work that it just doesn't need to. Since the frame will never be seen by the player, there is no point in wasting game time generating it.
It is worth pointing out that only the graphics part of the update is wasted. It is perfectly fine to update input, AI, or physics faster than the monitor can refresh. In fact, physics will be more accurate if the time step is smaller. We just want to really emphasize that there is absolutely no reason to draw frames faster than the monitor's refresh rate.
For most games this is never a problem. The usual solution to having a high frame rate is to do more work and make your game more interesting. If your game is too fast, draw more particles, have more enemies, calculate more accurate physics, or just do more physics effects. If you find that your game runs faster than 60 fps, your game probably isn't the best it could be. Again, there is no reason to draw more frames per second than can appear on screen.