The number of times per second a monitor refreshes the display is known as it's vertical refresh rate, or just refresh rate. The refresh rate of a monitor is measured in hertz (Hz). So, a monitor that can refresh the display 30 times per second has a refresh rate of 30 Hz. Many monitors refresh at 60 Hz, however, it is becoming common to see monitors with refresh rates of 120 Hz or even 240 Hz.
It is important to realize that the refresh rate of a monitor has nothing to do with the performance of a game or program. Having a monitor with a higher refresh rate will not improve the frame rate of a game, unless the game itself can support higher frame rates. The number of times a program updates the framebuffer is measured in frames per second or fps, and is completely independent from the number of times the monitor refreshes. When these two numbers are out-of-sync, the display will not look correct. Let's look at the problem of when the frames per second is less than the refresh rate:
These days, TV shows and movies are often displayed at 24 frames per second while the TV sets and monitors have a typical refresh rate of 60 Hz. In Figure 11.5, we have taken one second and split it into 60 red bars on the top to represent our refresh rate and 24 blue bars on the bottom to represent the frames of a movie. Each red bar represents the 1/60th of a second that the frame will be on screen. Each vertical dark red line represents when the monitor is refreshed.
As you can see, the refresh periods do not line up properly with the frames of the movie. In Figure 11.5 we can clearly see that Frame 1 is on screen for 3/60th (or 1/20th) of a second, while Frame 2 is only on screen for 2/60th (or 1/30th) of a second. Frame 1 is on screen longer than the original 1/24th of a second and Frame 2 is on screen less. Since the frames are not on screen for an equal amount of time, the video seems jittery. While this may not seem like much of a difference, some people are sensitive enough to notice a slight speeding up and slowing down effect:
TVs and movies have ways of adjusting for this problem, such as interpolating between frames. Since Frame 1 and Frame 2 are already known, it is easy to blend, interpolate, and generate intermediate frames before displaying them. However, that doesn't help us when our games are out-of-sync with the monitor.
Since games are interactive, the player's actions determine what will be displayed next on screen. The details of Frame 2 are determined by player input in response to Frame 1. This means that the contents of the framebuffer must be generated each frame, it can't be known ahead of time.
In the above example, we were simplifying a little by pretending that writing to the framebuffer was instantaneous. Of course, this isn't true. Even though the next frame of a movie is already known, it still takes time to write to the framebuffer. Unless we can copy to the framebuffer completely during the Vertical Blank Interval, we will need to write to the framebuffer while the display is being drawn on screen.
If we can time everything correctly, we can always write a pixel just after the electron gun has read it. However, if we are out-of-sync with the electron gun, eventually there will be a point when we haven't written the pixel for the current frame and the electron gun reads the old value. Let's look at this problem up close:
Figure 11.7 shows what we would like to see on screen. The left image is the position of a game object in frame 1. The right image is the ending position after the object has moved. These are two discrete points in time that we want to show. However, if the display is reading the pixels as we are writing them to the framebuffer, we can see a tearing effect if we haven't finished writing the current frame:
As we can see in Figure 11.8, the first image is correct. We are writing to a pixel after the display has read it. In the second image, the pixel being read has almost caught up to the pixel that is being written. At this point, the framebuffer contains half of each image. The third image shows that the display has overtaken the write pixel. The correct pixels have been written but they were written too late. The fourth image shows what the user would see on screen. Since the display read faster than the pixels could be written, the image looks as if it has been torn in half. This effect is known as tearing.
Tearing occurs when our frames per second and our refresh rate are out-of-sync. Unfortunately, it can be very difficult to get these two values perfectly aligned, and being a little off will cause some tearing. To solve this problem, we need to write out an entire frame of pixels before the display reads them.