Dev:2.5/Source/UI/BufferSwapping

Buffer Swapping

Blender should only redraw regions that have changed, instead of the full screen each time. This is important to work efficiently with big scenes, where drawing buttons and menus should be quick even if for example drawing the 3d view is slow. However, doing partial redraws of a screen in OpenGL has turned out to be tricky to implement in a way that is compatible with all operating systems, graphics cards, and driver versions.

Blender 2.4x

In 2.4x, the OpenGL front buffer was used for some things like menus or button highlights. Drawing in the front buffer is known to be suboptimal for performance, and caused big slowdowns on some ATI and Intel graphics cards. Since front buffer drawing is so poorly supported, we decided to not allow any use of it in 2.5.

Another mechanism that was used in 2.4x requires knowledge about how OpenGL swaps the front buffer and back buffer. One method is to simply exchange them, and the other is to copy the back buffer to the front buffer. Standard OpenGL says that the back buffer is undefined after swapping. All known implementations use either exchange or copy, but we do not have a reliable way to detect which of the two is actually being used. It can also change dynamically on some drivers, for example when going fullscreen.

Blender 2.5x

In 2.5, various methods to achieve partial redrawing with OpenGL have been implemented. The various methods implemented are available as option in the user preferences, under System, Window Draw Method. Currently a few extra methods are being implemented, after which we will gather information on how each of these performs with various platforms and cards. Based on that we can then choose a good default, and automatically use different methods by detecting the operating system and graphics card if needed.

Methods

Full

This method does a full redraw of the screen each time. This is used as a reference, and fallback in case all other methods fail.

• + Always works
• - No partial redraws

Triple Buffer

A third buffer (texture) the size of the screen is created, in addition to the back and front buffers. On each redraw, this texture is drawing into the back buffer. Changed area regions are then drawn into the back buffer, and the result is copied again in the third buffer. After that all overlapping menus, brushes, etc are drawn over the back buffer. These are redrawn always, as it is assumed they are quick to draw.

For cards without non-power of two texture support up to 9 textures may be created to avoid wasting too much memory on a power of two texture that is bigger than the screen.

• + No unneeded area region redraws.
• + Supported in old OpenGL versions.
• - Uses more GPU memory for the third buffer.
• - Copying to the third buffer is slow on some cards.

Triple Buffer FBO (in development)

This one also works with a third buffer, but rather than copying from the back buffer into the third buffer, all drawing happens in the third buffer. This is then drawn into the back buffer each time, after which the overlapping regions are redrawn. It does require support for the relatively new framebuffer object extension.

• + No unneeded area region redraws.
• + Less overhead than Triple Buffer.
• - Requires new OpenGL versions.
• - Uses more GPU memory for the third buffer.

Overlap

The next method works based on the knowledge of either swap exchange or copy being used by the driver. Since it assumes the back and front buffers to be (partially) preserved through swapping operations, it will track which area regions are valid in both, and redraws the ones that are not valid anymore. In the case of swap exchange this means some area regions need to be drawn twice instead of once, though for the cases of animation playback or transform dragging this is not the case.

The disadvantages are that we do not (yet) have a way to detect which swap method the driver uses. It also does not efficiently support redrawing for example menus or brush overlapping a 3d view, if those change everything below it has to be redrawn as well.

• + No extra memory usage.
• + Worked in 2.4x in many cases.
• - Too much redraw for overlapping menus.
• - No reliable way to detect swap method yet.

Restore (in development)

This method works much like overlap, but it also handles overlapping menus and brushes. When a new overlapping regions is created, the image below it is backed up to a texture, which is then used on subsequent redraws.

• + Little unnecessary redrawing.
• + Worked in 2.4x in many cases.
• - Needs some extra memory (depending on size of overlapping region).
• - No reliable way to detect swap method yet.