So now we have seen both situations where our frame count is out-of-sync with our refresh rate. In both cases we can have tearing, and in the case of a very high frame rate, we are wasting CPU/GPU cycles that could be used to improve our game. We want to avoid tearing. We want to be in-sync with the monitor refresh. How can we solve this problem?
The solution is the Vertical Blank Interval. Remember that the Vertical Blank Interval is when the electron gun is repositioning itself from the last pixel on the display back to the first pixel. During this short period, the entire display has been drawn and the front buffer isn't being used. This period is too short to copy all the contents of the back buffer to the front buffer. However, it is long enough to swap the pointers, which is how the page flipping mechanism works.
Modern computer monitors and TVs can send a signal back to the computer when the Vertical Blank, Interval, or V-Blank occurs. The graphics card waits until a V-Blank before swapping the buffers after the back buffer is completely drawn. This guarantees that there will never be tearing because parts of different frames can never be read in a single refresh.
As we said, double buffering is implemented at the hardware level. This is also true of synchronizing with the Vertical Blank Interval. By using a 3D graphics API such as DirectX or OpenGL, you get this for free. This V-Blank syncing or VSync is an option that must be enabled when initializing graphics. Once VSync is turned on, we don't need to worry about tearing. Additionally, the game will never generate more than one frame per monitor refresh because the graphics card will always wait for the V-Blank signal before swapping the buffers.
Syncing with the refresh rate of the monitor is a great way to prevent tearing. If a game can update 60 or more times a second, the back buffer and the front buffer will always be able to swap and we will have a smooth, tear-free game. However, we haven't talked about what happens if the back buffer isn't ready to be swapped because the frame is taking longer than 1/60th of a second to complete.
It is important to understand that the front and back buffers do not swap automatically every time the V-Blank signal arrives. Instead, the swap is performed at the request of the programmer. A function call is made to tell the graphics card that a new frame is prepared and the buffers should be swapped. This swap will happen immediately if VSync is turned off. However, if the VSync is turned on, the graphics card will wait for the V-Blank signal to arrive, no matter how long that is. If our update is just 1/100th slower, meaning a frame takes 1/59th of a second to complete, we will miss the V-Blank and need to wait for the next one.
Since the current frame wasn't ready, the monitor displays the previous frame again. The same frame will be on screen for 1/30th of a second. Since the back buffer must wait to be swapped until the next V-Blank, our game can't start working on the next frame. Our game is idle while waiting for the V-Blank. This means that if our game is using VSync and it can't achieve 60 frames per second, our frame rate will drop down to 30 frames per second. If our game can't achieve 30 frames per second, our frame rate will take 3/60th of a second, or 20 fps.
For some programmers and some games, achieving 30 frames per second is perfectly fine. To implement more beautiful effects or more accurate physics, dropping to 30 frames per second might be an important trade off. Everyone must decide for their own game what is right. However, many players simply do not like 30 frames per second. Players often say they can notice more jittery movement and more importantly, they notice input lag.
Remember, if we can't achieve our goal of 60 fps, the graphics card must wait for the next V-Blank before returning from the swap call. This means that our game can't process physics, AI, or even input. The player is seeing half as many frames on screen, which means objects are moving more each frame. Additionally, input is now being gathered from the player once every 1/30th of a second instead of once every 1/60th of a second. While this may not seem like much, for fast, twitch response games such as First Person Shooters, this can be too long.
Figure 11.12 shows an example of the contents of both the front and back buffers in a VSync scenario where a game can't update at the same rate as the monitor. The display refreshes every 1/60th of a second or every 0.0167 seconds. The game can update every 1/50th of a second or every 0.02 seconds. In the image below, the monitor refreshes are colored red or green. The red refreshes are when the game frame isn't ready and so the previous frame is displayed. The green refreshes are when the game frame is ready and so the buffers are swapped.
The blue represents when the game frame is completed. This doesn't mean that the new frame is instantly displayed. This is because the graphics card waits until the next refresh to swap buffers. It is important to understand that the game doesn't update every 1/50th of a second for the same reason. Instead, each game update is 1/50th of a second after the last buffer swap:
