Double Buffering: Difference between revisions
+Cat: Video, some minor fixes and code/pre block → source block
| [unchecked revision] | [unchecked revision] |
(+Cat: Video, some minor fixes and code/pre block → source block) |
|||
Line 4:
== 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 <code>0xB800</code> (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), <code>0xB800</code> would represent buffer A (the front-buffer) whilst buffer B is created and allocated by your favourite <code>malloc</code> function (or <code>new[]</code> operator).
==== Where To Write To ====
Instead of writing directly to console video memory (at <code>0xB800</code>), 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.
Line 14:
==== Important Note ====
I used console video memory as an example here, as
==== Example ====
For example, without double buffering consider a simple game rendering:
<code>void run()▼
<source lang="c">
{
while(running)
Line 32 ⟶ 34:
draw_characters();
}
}
</source>
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 <code>draw_characters()</code> you would call:
<source lang="c">
</source>
so the final image in it's entirety is sent to the frame buffer, not just parts of it.▼
== Advantages ==
Line 47 ⟶ 52:
* 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
== Disadvantages ==
Line 53 ⟶ 58:
=== Memory requirement ===
You need to create a second buffer with the same size of the
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
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
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).
Line 72 ⟶ 77:
==== Vertical Synchronization ====
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
<source lang="cpp">
/* handle VBLANK, called by the interrupt handler */
Line 111 ⟶ 117:
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 loosing a few
==== 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.
▲Each window could consist own 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 it's back buffer and send it it's 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
== Examples ==
Line 283 ⟶ 288:
</source>
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 [[
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
I've used some sort of loop here (it looks like a game loop), but remember that most
▲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 GUI's (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 API's 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.
[[Category:Video]]
▲I've used some sort of loop here (it looks like a game loop), but remember that most GUI's on OS' 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 occassions such as moving or resizing the control.
| |||