# Double Buffering

An introduction to double buffering - the foundational technique behind real time graphics
This lesson is part of theÂ course:

### Intro to Programming

Become a software engineer with C++. Starting from the fundamentals, we guide you step by step along the way, finishing off with a portfolio-ready capstone project.

###### Ryan McCombe

In the previous lesson, we described a typical gameÂ loop:

1. Get input
2. Update all our objects
3. Render the frame

The transition from step 2 to step 3 warrants some further explanation. There is some theory here that is very important to understanding how SDL, and real time graphics in general,Â works.

In computer graphics, we simulate movement by quickly showing a sequence of still images, typically calledÂ â€śframesâ€ť.

A lot of complexity and elaborate algorithms can go into generating these frames. But, after all the processing, weâ€™re just with a collection of pixel colors we want to show theÂ user.

## What are Buffers?

A buffer is an area of memory where data is stored for a short period of time. Frames are buffers - we can think of them as big arrays of pixel objects. Our goal boils down to determining which color each pixel needs to be, and to write those values into theÂ buffer.

The problem is that we canâ€™t do that all at once. It takes many statements, function calls and calculations to generate a frame, and they donâ€™t all complete at the sameÂ time.

That presents a problem for our users - we donâ€™t want them to witness the frame being constructed. That would shatter the illusion. So, we invented doubleÂ buffering.

## Double Buffering

With double buffering, we have, predictably, two buffers. Thereâ€™s the one the user is seeing, and the one weâ€™re building to show to themÂ next.

The buffer the user is seeing is called the â€śfront bufferâ€ť, and the one weâ€™re building is the â€śback bufferâ€ť. When weâ€™ve completely finished building the back buffer, we swap themÂ around.

The back buffer becomes the front buffer and is shown to our users. The front buffer becomes the back buffer, and we start creating our next frame inÂ it.

This is typically managed on the GPU but, were we to create the effect in C++, we could imagine it being something likeÂ this:

using Buffer = std::vector<Pixel>;
Buffer A;
Buffer B;

Buffer* Front { &A };
Buffer* Back { &B };

while(true) {
DrawEnvironment(Back);
DrawCharacters(Back);
DrawUI(Back);
std::swap(Front, Back);
}


## Double Buffering in SDL2

In SDL2, the double buffering is mostly handled for us. When we use commands like SDL_FillRect, SDL ensures this is being done on the backÂ buffer.

However, we do need to tell SDL when it needs to swap buffers. When weâ€™re working with window surfaces, that command is SDL_UpdateWindowSurface.

If weâ€™re making changes in our application, and those changes do not seem to be appearing, the first thing we should do is make sure weâ€™re calling SDL_UpdateWindowSurface after making ourÂ changes.

In our example application loop from the previous lesson, we were calling this function as the final step of the loop. This ensures our buffers are swapped as quickly as possible, maximising our frameÂ rate.

### Theory: Screen Tearing and VSync

It's generally beyond the scope of this course, but as an aside for anyone who has heard the phrases, and wants some more context on what they are. These two concepts are inherently linked to the multiple buffer setup we're discussingÂ here.

Once our software implements double buffering, thereâ€™s an unpleasant interaction that can happen with ourÂ hardware.

This is because computer monitors donâ€™t update their display all at once - that is also a process that takes some time. If we trigger our swap in the middle of that process, part of the monitor can show one frame, whilst another part shows a different frame. This is what causes screenÂ tearing.

It is also why screen tearing is more common at higher frame rates. Higher frame rates means more frequent swaps, which means more swaps happening at the same time the monitor isÂ refreshing.

There are various options for dealing with this, a popular one being synchronizing the applicationâ€™s refresh rate with the hardware refresh rate. Variations of this idea are commonly called vertical syncÂ (vsync).

### Theory: Triple Buffering

When our refresh rate is synchronized with the hardwareâ€™s refresh rate, this presents an interesting problem for us. When we complete the next frame, it needs to wait in the back buffer until the hardware is ready forÂ it.

So, weâ€™re left sitting with a completed frame in both our buffers. Until the hardware requests the swap, we canâ€™t start working on our next frame. Predictably, this is the use case for adding yet another buffer to the process. With triple buffering, weÂ have:

1. The front buffer, which the user is currently seeing
2. The middle buffer, which has a completed frame ready to be used the next time the monitor updates
3. The back buffer, where weâ€™re creating the frame to come after that

This lesson is part of theÂ course:

### Intro to Programming

Become a software engineer with C++. Starting from the fundamentals, we guide you step by step along the way, finishing off with a portfolio-ready capstone project.

• 77.Making Minesweeper with C++ and SDL2
• 78.Project Setup
Paid Promotions
Next Lesson

### Keyboard and Mouse Input in SDL2 (C++)

Learn how SDL2 handles user input, and how we can react to it to update our application in real time.
ContinueView Course