A programming technique used to create smoother flowing graphics.

The way to do this is to have a chunk of memory as a buffer for your screen. Polygons, sprites, or whatever are drawn onto this buffer. Once it’s finished drawing the current frame, it copies the buffer onto the screen and starts drawing the next frame on the buffer. This creates smoother graphics by having complete frames spend more time on the screen rather than incomplete/being_worked_on frames.

This technique is similar to page flipping except it uses regular memory rather than video memory.

A more general use of double buffering is when 2 entities A and B need to pass each other information in a situation where it is crucial that B receives an uninterrupted flow of data, and where a large single buffer is not feasible. A and B may be 2 parts of the same program, 2 different processes on the same computer etc.

To do double buffering, you need 2 buffers b1, b2 and some communication mechanism between A and B. Often this is a set of flags or callbacks.

Generally A fills up the buffers, then tells B that it is ready. B will then start reading out of b1. When B is done it tells A that it is through with b1, and starts reading from b2. When everything goes to plan, by the time B has finished reading b2, A has filled b1 with some tasty new data and so B can read from b1 again. This continues as long as A and B feel like it. As you can see this will usually mean B never has to wait for data (at the expense of a little more memory overhead).

Now for an example of some hardcore double buffering action! Let us travel back in time to the days of Mac OS 9, in particular lets have a look at the Sound Manager API that was present until Mac OS 9.x, where my good friend SndPlayDoubleBuffer lives. The brightest among you will probably have guessed that this function uses double buffering. It was mainly used to be able play background music or looping sounds continously without having to load too much of the sound data into memory at a time. The need for double buffering is obvious here. If the sound hardware has to wait for data your music is going to get all horrible and choppy. You gave SndPlayDoubleBuffer buffers and a callback and when it had finished reading from one of the buffers it would call your callback and tell you it was ok to refill that buffer.

SndPlayDoubleBuffer is not included in the Carbon specification. After many years of loyal services, its home is now the great header file in the sky.

One of the prime reasons for double buffering in computer video is due to the behavior of Cathode Ray Tubes (CRTs). Your average CRT consists of an electron gun pointed at an array of rasters, which make up the screen. Each physical pixel on a CRT is comprised of three phosphors, red, green and blue.

The CRT functions by using magnetic fields to aim electrons from the electron gun at these rasters. The electrons are charged precisely so that they will excite the phosphores in the screen and each raster will then display a color based on the additive sum of the excitation of the red, green, and blue elements.

However this is still a serial device, the electron gun excites one raster, then the next, usually in a pattern that starts at the top left corner, travels to the top right corner, and then moves down one row (a scanline), and repeats the process across the next row of rasters.

After all of the rasters on your screen have been drawn, the gun then moves from the bottom right corner to the top left corner and starts the whole process over again. This all happens so rapidly that your eye never catches it. On a 75 hz monitor, the entire process happens 75 times per second.

Now the basic way this works with your computer is to have a buffer, in which each value dictates what color an individual raster should be. Prior to double buffering, you would draw into the same buffer which the CRT would read the raster colors from. If you drew into this buffer at a place where the CRT was in the middle of reading values for rendering to the screen from, there would be a mismatch and the CRT would end up creating an artifact until the next scan cycle. When the screen is being animated on a per-pixel basis in rapid succession, this leads to alot of artifacts being generated. Double buffering is the de facto solution to combat this problem. Your drawing application draws into one buffer, and when it is done drawing it swaps this buffer with the one the screen reads from. When it has finished drawing the next complete frame of animation it then flips the buffers and continues this process ad infinitum. As long as the buffer flip operation is very fast, the drawing and rendering operations can operate independently of each other without any significant artifact generation.

Log in or register to write something here or to contact authors.