One of the most exciting things you can do on a graphics computer is draw pictures that move. Whether you’re an engineer trying to see all sides of a mechanical part you’re designing, a pilot learning to fly an airplane using a simulation, or merely a computer-game aficionado, it’s clear that animation is an important part of computer graphics.
In a movie theater, motion is achieved by taking a sequence of pictures and projecting them at 24 frames per second on the screen. Each frame is moved into position behind the lens, the shutter is opened, and the frame is displayed. The shutter is momentarily closed while the film is advanced to the next frame, then that frame is displayed, and so on. Although you’re watching 24 different frames each second, your brain blends them all into a smooth animation. (The old Charlie Chaplin movies were shot at 16 frames per second and are noticeably jerky.) Computer-graphics screens typically refresh (redraw the picture) approximately 60 to 76 times per second, and some even run at about 120 refreshes per second. Clearly, 60 per second is smoother than 30, and 120 is perceptively better than 60. Refresh rates faster than 120, however, may approach a point of diminishing returns, depending on the limits of perception.
The key reason that motion picture projection works is that each frame is complete when it is displayed. Suppose you try to do computer animation of your million-frame movie with a program such as this:
If you add the time it takes for your system to clear the screen and to draw a typical frame, this program gives increasingly poor results, depending on how close to 1/24 second it takes to clear and draw. Suppose the drawing takes nearly a full 1/24 second. Items drawn first are visible for the full 1/24 second and present a solid image on the screen; items drawn toward the end are instantly cleared as the program starts on the next frame. This presents at best a ghostlike image, as for most of the 1/24 second your eye is viewing the cleared background instead of the items that were unlucky enough to be drawn last. The problem is that this program doesn’t display completely drawn frames; instead, you watch the drawing as it happens.
Most OpenGL implementations provide double-buffering—hardware or software that supplies two complete color buffers. One is displayed while the other is being drawn. When the drawing of a frame is complete, the two buffers are swapped, so the one that was being viewed is now used for drawing, and vice versa. This is like a movie projector with only two frames in a loop; while one is being projected on the screen, an artist is desperately erasing and redrawing the frame that’s not visible. As long as the artist is quick enough, the viewer notices no difference between this setup and one in which all the frames are already drawn and the projector is simply displaying them one after the other. With double-buffering, every frame is shown only when the drawing is complete; the viewer never sees a partially drawn frame.
A modified version that displays smoothly animated graphics using doublebuffering might look like the following:
The Refresh That Pauses
For some OpenGL implementations, in addition to simply swapping the viewable and drawable buffers, the swap_the_buffers() routine waits until the current screen refresh period is over so that the previous buffer is completely displayed. This routine also allows the new buffer to be completely displayed, starting from the beginning. Assuming that your system refreshes the display 60 times per second, this means that the fastest frame rate you can achieve is 60 frames per second (fps), and if all your frames can be cleared and drawn in under 1/60 second, your animation will run smoothly at that rate.
What often happens on such a system is that the frame is too complicated to draw in 1/60 second, so each frame is displayed more than once. If, for example, it takes 1/45 second to draw a frame, you get 30 fps, and the graphics are idle for 1/30 -1/45 = 1/90 second per frame, or one-third of the time.
In addition, the video refresh rate is constant, which can have some unexpected performance consequences. For example, with the 1/60 second per refresh monitor and a constant frame rate, you can run at 60 fps, 30 fps, 20 fps, 15 fps, 12 fps, and so on (60/1, 60/2, 60/3, 60/4, 60/5,…). This means that if you’re writing an application and gradually adding features (say it’s a flight simulator, and you’re adding ground scenery), at first each feature you add has no effect on the overall performance—you still get 60 fps. Then, all of a sudden, you add one new feature, and the system can’t quite draw the whole thing in 1/60 of a second, so the animation slows from 60 fps to 30 fps because it misses the first possible buffer-swapping time.
A similar thing happens when the drawing time per frame is more than 1/30 second—the animation drops from 30 to 20 fps.
If the scene’s complexity is close to any of the magic times (1/60 second, 2/60 second, 3/60 second, and so on in this example), then, because of random variation, some frames go slightly over the time and some slightly under. Then the frame rate is irregular, which can be visually disturbing.
In this case, if you can’t simplify the scene so that all the frames are fast enough, it might be better to add an intentional, tiny delay to make sure they all miss, giving a constant, slower frame rate. If your frames have drastically different complexities, a more sophisticated approach might be necessary.
Motion = Redraw + Swap
The structure of real animation programs does not differ very much from this description. Usually, it is easier to redraw the entire buffer from scratch for each frame than to figure out which parts require redrawing. This is especially true with applications such as three-dimensional flight simulators, where a tiny change in the plane’s orientation changes the position of everything outside the window.
In most animations, the objects in a scene are simply redrawn with different transformations—the viewpoint of the viewer moves, or a car moves down the road a bit, or an object is rotated slightly. If significant recomputation is required for nondrawing operations, the attainable frame rate often slows down. Keep in mind, however, that the idle time after the swap_the_buffers() routine can often be used for such calculations.
OpenGL doesn’t have a swap_the_buffers() command because the feature might not be available on all hardware and, in any case, it’s highly dependent on the window system. For example, if you are using the X Window System and accessing it directly, you might use the following GLX routine:
If you are using the GLUT library, you’ll want to call this routine:
Example 1-3 illustrates the use of glutSwapBuffers() in drawing a spinning square, as shown in Figure 1-3. This example also shows how to use GLUT to control an input device and turn on and off an idle function. In this example, the mouse buttons toggle the spinning on and off.
Figure 1-3 Double-Buffered Rotating Square
Example 1-3 Double-Buffered Program: double.c
