Double Buffering

Difficulty level
Beginner

Double-buffering is a term that is well known throughout the graphics industry. Most applications (primarily games) seldom work without it as it has many advantages over single-buffering (but also has a few disadvantages).

What Is It?

The Buffers

Double-buffering possibly sounds harder than it actually is. In theory, you have a buffer A and a buffer B, which are usually respectively called the front-and back-buffer. On single-buffered displays, you draw straight to video memory, so suppose video memory is located at address 0xB800 (like console video memory is), you just start modifying values starting from this address (as you probably know) to show characters on the screen. If you would do this with double-buffering (which isn't a very good idea with console video memory, by the way), 0xB800 would represent buffer A (the front-buffer) whilst buffer B is created and allocated by your favourite malloc function (or new[] operator).

Where To Write To

Instead of writing directly to console video memory (at 0xB800), you write everything to the address where Buffer B is located. The process of drawing characters is exactly the same as before, except you're now writing to another memory address. When you're done drawing, you copy the contents of the back buffer (buffer B) to the front buffer (buffer A). This process is commonly called 'swapping the buffers', though swapping isn't interpreted as switching the contents around, but more of in 'switching the order of the buffers'. By 'swapping the buffers', the back buffer is now seen by the user and carries the same pixel values as the front buffer. The back buffer can then be freely modified again until ready to be then swapped again.

What Actually Is Seen

When using double-buffering, the user is looking at Buffer A while you're drawing to Buffer B. When using single-buffering, the user is looking at buffer A at the same time you're modifying that buffer. So that means the user doesn't see any pixels being modified at the moments he or she is looking at the screen. He or she will notice the changes as soon as you swap the buffers.

Important Note

I used console video memory as an example here, as practically every OS developer knows how to use this, but it is still not recommended to use double-buffering on a console display, as it is practically useless and wastes memory (unless you're using some kind of game loop for your OS). Double-buffering can be very useful when you're building your own GUI though. On console displays, you usually also don't need double-buffering since there are no problems with artifacts.

Example

For example, without double buffering consider a simple game rendering like the following:

void run()
{
    while(running)
    {
        /* update input */

        /* update game logic */

        clear_screen();
        draw_background();
        draw_levels();
        draw_picksup();
        draw_characters();
    }
}

Now imagine if each of those functions drew directly to the frame buffer. The video card and monitor may update just after you have drawn the background, or it may update just after you have cleared the screen. More likely, you're going to end up with a combination of effects with resulting in your screen flickering and seeing through objects.

Now imagine if each of these functions drew to a secondary buffer the size of the frame buffer. Each time you modify a pixel it won't be writing directly to the video card. Instead, after draw_characters() you would call:

memcpy(framebuffer, backbuffer, width * height * bytesperpixel);

so the final image in its entirety is sent to the frame buffer, not just parts of it.

Advantages

Now why would you want to use double-buffering over single buffering in e.g. your GUI, games, or video displays? Well, the main advantages of double-buffering are:

• The user does not see every pixel modification (so if the same pixel gets modified 5 times, the user will only see the last one). This helps preventing 'flickering' (or screen flashes).
• Double-buffering usually takes care of artifacts you or the user might be experiencing.
• Writing to video memory is only performed once, on the buffer swap, instead of repeatedly for every pixel of which some might be overlapped later and might be invisible.

Disadvantages

Even though double-buffering is useful, it also has negative characteristics. Each is listed with an explanation and a possible solution.

Memory requirement

You need to create a second buffer with the same size of the video memory (and for large displays such as 1280x1024x32 this can be an expensive cost).

This is more of an issue on embedded and older systems with limited memory. In the example of 1280x1024x32, this would mean your application or video driver would need to allocate an extra 5 megabytes, which isn't an expensive once off cost in a modern system that has between several hundred megabytes to several gigabytes of memory.

Also, virtually every modern desktop computer has a dedicated graphics accelerator card which has its own inbuilt memory. While older graphics cards may only have 8MB, many newer high-end models can have close to several gigabytes. This is more than sufficient to store the back buffer in, as well as being optimized for this purpose. An OS should allow the video driver to allocate and manage the double buffer since each graphics vendor will usually have their own implementation.

Note that the buffer doesn't always have to have the same size as the video memory, there are also other ways to do double-buffering, for one you could also have some sort of compression system where a number indicates how many pixels have the same value. Then again, that would have an extra performance cost if not done efficiently. Below you'll find an example of how to create a basic double-buffering system.

Speed

You need to copy the back buffer to the front buffer every time the buffer needs to be swapped (in games with a frame-rate of 30, 30 times each second). So better make sure your memcpy and other memory functions are optimized!

However, some graphics cards have the ability to specify the address in memory where the buffer used for rendering is stored. If you're redrawing the entire scene each frame (which is often the case when rendering video or 3D), you simply need to swap two pointers (the pointer to the buffer you're drawing to, and the pointer to the buffer being drawn on screen).

Tearing

Tearing (example image) is an artifact when the buffer is being updated while the graphics card and monitor are midway through updating the screen. The side effect is that parts of multiple frames end up being sent to the monitor at the same time. Tearing is most noticeable at animation at extremely high frame rates (100fps+) with low refresh rates (60Hz) and less noticeable vice verse, though it happens whenever the refresh rate does not match the frame rate.

Tearing can usually be ignored in general applications (office suites, web browsers, terminals) since the entire screen isn't constantly being updated. However, it still occurs, for example dragging a window around fast in a window manager that does not account for tearing.

Vertical Synchronization

Vertical synchronization, more commonly known as v-sync, is when the frame rate is synchronized to match the vertical refresh rate of the screen. This means the double buffer is copied to screen's buffer in a small period between frames known as the vertical blanking interval. By updating the screen's buffer between frames, you ensure that only full frames are shown at a time.

To aid in synchronizing, virtually all video cards since the first home computers have the capability to enable an interrupt at the beginning of each vertical blanking interval (known as VBLANK).

An example of vertical synchronization is as follows:

/* handle VBLANK, called by the interrupt handler */
void vga_handleVBlank()
{
    if(vga_framerendered)
    {
        memcpy(vga_screen, vga_backbuffer, vga_width * vga_depth * vga_bytesperpixel);
        vga_framerendered = false;
    }
}

/* called when you finish drawing to the double buffer */
void vga_sync()
{
    vga_framerendered = 1;

    /* stick in a loop until the interrupt is fired */
    while(vga_framerendered);
}

There is no reason you HAVE to synchronize, another method could be you place a spinlock on the buffer, if you fail to acquire the lock simply skip that frame until you do. This may work fine in a video game where you redraw the frame over and over again so if you miss drawing something to the screen it will be redrawn on the following frame, but in a modern multitasking GUI environment this is unacceptable.

In a GUI environment synchronization becomes somewhat more complex. For example see below.

Unrelated, there is also a horizontal blanking interval, which is rarely utilized. The HBLANK interrupt fires when the display has finished drawing a line.

Triple buffering

Triple buffering is when three or more buffers are being used, at the cost of more memory to store these buffers in.

In a real-time application (such as a game) utilizing triple buffering there are two back buffers and one front buffer. The system renders one frame to one back buffer, the next frame the other back buffer, the next frame to the original back buffer, etc, constantly interchanging between the two. When the VBLANK interrupt fires, the last frame fully rendered is copied to the front buffer (done efficiently, this can be a case of testing one value and swapping two pointers inside the interrupt handler without any locking).

In a system already utilizing double buffering, triple buffering is simple to implement. In most cases it can be added to the video driver without the underlying system requiring any modifications.

If losing a few MBs of memory is not an issue then triple buffering provides several advantages. First off, there is no need to synchronize frames, so the drawing algorithm can run as often and as fast as it can. Secondly, some real time applications must perform a consistent number of update cycles each second, in which case synchronizing with the refresh rate (which will cause the program to slow down to the speed of the monitor) or skipping frames (the time it takes to execute a single update will not be consistent; some will render frames, some won't) is not an option.

Something unique?

In GUI applications, where multiple programs are rendering to multiple front and back buffers each at their own speed you need to be somewhat creative.

For example, a method that will work is: each window could consist of a double buffer (or a single buffer that is updated on a redraw/paint event), as well as a double buffer for the entire screen. That way each program can draw on its back buffer and send it its own front buffer when it has finished drawing (either swapping pointers or memcpy) as often as it wants (wrapping a lock around the back buffer), then when the GUI has detected the back buffer has changed, it copies the window's front buffer (locking it temporarily) into the screen's back buffer, then when the VBLANK fires the screen's back buffer is copied to the front buffer if the screen's back buffer has changed.

Each window manager usually has its own method. But like mentioned above, tearing is a relatively minor issue in most general GUI programs that can often be overlooked, since you will be dealing with text and images that won't be updating. Therefore, if the front buffer is in the middle of outputting to the monitor while copying the next frame to it, you might notice a slight flicker that lasts for all but 1 monitor refresh (which is no less than 1/60th of a second on most monitors).

Examples

Buffer Creating In C

/* Supposing the display is 800x600 with 32 bpp (meaning 32/8 = 4 bytes per pixel). */
byte *BackBuffer = ((byte *) (malloc(800 * 600 * 4)));

Buffer Creating In C++

/* Supposing the display is 800x600 with 32 bpp (meaning 32/8 = 4 bytes per pixel). */
byte *BackBuffer = new byte[800 * 600 * 4];

This implementation absorbs the same amount of memory the real video memory does, in this case, 800 * 600 * 4 = 1920000 bytes = about 1,83 MB. While using single-buffering needs 1,83 MB of RAM with our video resolution (only the display itself), double-buffering would require 2 * 1,83 MB = about 3,66 MB. The higher the resolution, the more memory is required. There are of course implementations that can use up less than that with special techniques, but for some OS developers, high resolutions, and especially with double-buffering, are expensive features.

Coding Examples

Articles with all theory are boring, so here are some examples of how to use double-buffering.

Example in C

byte VidMem;
byte BackBuffer;

unsigned short ScrW, ScrH;
unsigned char Bpp;

/*
 * Initializes video, creates a back buffer, changes video modes.
 * Remember that you need some kind of memory allocation!
 */
void InitVideo(unsigned short ScreenWidth, unsigned short ScreenHeight, unsigned char BitsPerPixel)
{
	/* Warning: 0xEEEEEEE servces as an example, you should fill in the address of your video memory here. */
	VidMem = ((byte *) 0xEEEEEEE);
	BackBuffer = ((byte *) (malloc(ScreenWidth * ScreenHeight * BitsPerPixel)));

	ScrW = ScreenWidth;
	ScrH = ScreenHeight;
	Bpp = BitsPerPixel;

	/* Switch resolutions if needed... */
	/* Do some more stuff... */
}

/*
 * Draws a pixel onto the backbuffer.
 */
void SetPixel(unsigned short X, unsigned short Y, unsigned Colour)
{
	/* Put a pixel onto the back buffer here. */
	/* Remember to write to the BACK buffer instead of the FRONT buffer (the front buffer represents your video memory). */
}

/*
 * Swaps the back and front buffer.
 * Most commonly done by simply copying the back buffer to the front buffer.
 */
void SwapBuffers()
{
	/* Copy the contents of the back buffer to the front buffer. */
	memcpy(VidMem, BackBuffer, ScrW * ScrH * Bpp);
}

/*
 * An example of how to use these functions.
 */
void ProgramLoop()
{
	while(Program_Is_Running)
	{
		/* Handle events, update window coordinates and other things, ... */

		/*
		 * You should probably implement some sort of FillScreen or FillRect function,
		 * or something that clears the back buffer before drawing. Setting the entire
		 * back buffer to 0 (black) will suffice for a basic system.
		 */
		memset(Backbuffer, 0, ScrW * ScrH * Bpp);

		/* Draw everything: a GUI, windows, other things. This example puts 2 white pixels on the screen. */
		SetPixel(50, 50, 0xFFFFFF);
		SetPixel(25, 25, 0xFFFFFF);

		/* When done drawing, swap the buffers and let the user see what you've drawn. */
		SwapBuffers();
	}
}

Example in C++

byte VidMem;
byte BackBuffer;

unsigned short ScrW, ScrH;
unsigned char Bpp;

/*
 * Initializes video, creates a back buffer, changes video modes.
 * Remember that you need some kind of memory allocation!
 */
void InitVideo(unsigned short ScreenWidth, unsigned short ScreenHeight, unsigned char BitsPerPixel)
{
	/* Warning: This is an example, you should fill in the address of your video memory here. */
	VidMem = (reinterpret_cast<byte *>(0xEEEEEEE));
	BackBuffer = new byte[ScreenWidth * ScreenHeight * BitsPerPixel];

	ScrW = ScreenWidth;
	ScrH = ScreenHeight;
	Bpp = BitsPerPixel;

	/* Switch resolutions if needed... */
	/* Do some more stuff... */
}

/*
 * Draws a pixel onto the backbuffer.
 */
void SetPixel(unsigned short X, unsigned short Y, unsigned Colour)
{
	/* Put a pixel onto the back buffer here. */
	/* Remember to write to the BACK buffer instead of the FRONT buffer (the front buffer represents your video memory). */
}

/*
 * Swaps the back and front buffer.
 * Most commonly done by simply copying the back buffer to the front buffer.
 */
void SwapBuffers()
{
	/* Copy the contents of the back buffer to the front buffer. */
	memcpy(VidMem, BackBuffer, ScrW * ScrH * Bpp);
}

/*
 * An example of how to use these functions.
 */
void ProgramLoop()
{
	while(Program_Is_Running)
	{
		/* Handle events, update window coordinates and other things, ... */

		/*
		 * You should probably implement some sort of FillScreen or FillRect function,
		 * or something that clears the back buffer before drawing. Setting the entire
		 * back buffer to 0 (black) will suffice for a basic system.
		 */
		memset(Backbuffer, 0, ScrW * ScrH * Bpp);

		/* Draw everything: a GUI, windows, other things. This example puts 2 white pixels on the screen. */
		SetPixel(50, 50, 0xFFFFFF);
		SetPixel(25, 25, 0xFFFFFF);

		/* When done drawing, swap the buffers and let the user see what you've drawn. */
		SwapBuffers();
	}
}

I believe this example is mostly clear. As there are too many different ways of changing video modes or putting pixels, I'm going to let you fill that in yourself. If you want more information, you can go to the GUI or the Drawing In Protected Mode pages.

Note also that the above code might be very 'irregular'. As you know, there is no limit on the drawing, so it is possibly that the first draw takes 30 milliseconds, while the second draw takes 40 milliseconds or the first few seconds, you have a frame-rate of 100 frames per second whilst the next couple of seconds, you have a frame-rate of only 20 frames per second. Because of this, drawing times are usually capped. In the most common GUIs (such as the one in Windows), this is not really of any importance, since only parts of the screen are redrawn if they are 'invalidated' (usually referred to as 'Invalidated rectangles'), but in games, the screen is being constantly redrawn, usually up to 60 times per second. Today's APIs usually clamp this value to the screen refresh rate, this is why they usually have values such as '60' or '75'. Normally, a frame-rate of 25 to 30 suffices to have a 'smooth' display.

I've used some sort of loop here (it looks like a game loop), but remember that most GUIs on most OSes do not work with game loops, they usually work with some sort of invalidation system. Meaning a control is redrawn only if it is invalidated, which happens on occasions such as moving or resizing the control.