影像緩衝區

影像緩衝是記憶體的一部分，圖形引擎通過更新影像緩衝，將要在顯示器上顯示的下一幅圖像包含進來。

幀緩衝是RAM的一個連續部分，具有指定大小。

影像緩衝記憶體

影像緩衝具有相應的寬度和高度。 因此，我們通常將影像緩衝視為記憶體的一個二維部分，可通過x、y座標檢索。

二維影像緩衝記憶體

影像緩衝具有相應的色彩格式。 影像緩衝中的每個條目都是該色彩格式下的色彩。 我們將影像緩衝中的每一個這樣的條目稱為像素。

通過計算影像緩衝中像素的儲存位址和更新存儲的色彩，可以更新影像緩衝中位置 x,y 處的像素色彩。

uint32_t pixelAddress = x + y * WIDTH;
framebuffer[ pixelAddress ] = newColor;

同樣地，我們可以獲取影像緩衝中像素的色彩並用在計算中。 例如，暗化影像緩衝中像素的色彩（假設有暗化函數可用）。

uint32_t pixelAddress = x + y * WIDTH;
framebuffer[ pixelAddress ] = darken( framebuffer[ pixelAddress ] );

對於影像緩衝記憶體，通常不會如前文所述逐一讀寫像素，而是利用系統的底層硬體功能（如Chrom-ART DMA）進行讀寫。

顏色

在TouchGFX中，影像緩衝的像素色彩格式可以是：

• 灰度1、2或4位元每像素（bpp）灰度，或者
• 高或真彩16、24或32 bpp色彩

每個像素使用的位元數越多，影像緩衝能夠呈現的顏色就越清晰，此外，每個像素使用的位元數越多，影像緩衝消耗的儲存空間就越多。

Display

影像緩衝的內容最終會被傳輸並顯示在顯示器上。 因此，影像緩衝與顯示器的像素寬度和高度相同是十分常見的。

24 bpp影像緩衝內容和顯示器顯示內容

Further reading

參見關於顯示器技術的部分瞭解不同顯示器類型。

影像緩衝的位置

下面是一個基於微控制器的繪圖系統的簡圖。

繪圖系統簡圖

影像緩衝可以位於MCU或外部RAM中。

影像緩衝的可能位置

每個可能位置都具有潛在的優勢和不足。

內部RAM

如果影像緩衝位於MCU內部的RAM中，對影像緩衝的讀和寫存取會盡可能快地完成。 這意味著TouchGFX應用的運行會盡可能平穩。 反過來，內部RAM是十分稀少的資源，被系統的許多元件使用，因此，影像緩衝大量佔用內部RAM也不可行。

如果可行，由於無需額外的RAM，在內部RAM中提供影像緩衝可以降低系統的總體成本。

外部RAM

如果系統有外部RAM，可以選擇在外部RAM而不是內部RAM中提供影像緩衝。 對外部RAM的讀和寫存取通常會比內部RAM慢，但外部RAM的空間量通常大得多。 因此，有時候這是唯一可行的解決方案。

MCU可能具有一些功能（如快取記憶體），可加快外部RAM的存取速度。 參見關於MCU的部分瞭解詳細資訊。

Display with GRAM

Depending on the type of display in the system there might be memory embedded on the display (often called GRAM). 此記憶體儲存顯示器“實際”像素的內容。 顯示器中有此像素記憶體，意味著在顯示器仍活動時，MCU可能處於空閒狀態。

由於顯示器記憶體並非記憶體映射，既不打算也不適合用於像素的隨機讀取或寫入，因此不可能在顯示器RAM中提供TouchGFX影像緩衝。 相反，TouchGFX將影像緩衝置於內部或外部RAM中，並在適當的時候將其傳輸到顯示器RAM。

儲存空間消耗

影像緩衝中的色彩數量和像素數量決定了影像緩衝消耗的儲存空間。

影像緩衝使用的儲存空間通常為 寬 高 以位元數計的色深 / 8 位元組數。

解析度（像素）	色彩（bpp）	計算	消耗的儲存空間（位元組）
800x480	16 bpp	800 480 16 / 8	768,000 B
480x272	24 bpp	480 272 24 / 8	391,680 B
100x100	8 bpp	100 100 8 / 8	10,000 B

當具有一個以上的影像緩衝時，消耗的存儲空間相對地較大。 例如，當使用雙重影像緩衝方案時，使用兩個影像緩衝會消耗兩倍的儲存空間。

當影像緩衝不足一個時，由應用明確地分配和控制存儲空間的量。 因此，存儲空間的消耗量是完全可定制的，但應注意的是，使用量過少會影響整體圖形性能。

Framebuffer Strategies

Framebuffer strategy is a core feature, that enables you to make the most optimal match between TouchGFX rendering and your existing hardware (MCU, RAM and Display). In case you are selecting new hardware, it is recommended to get familiar with the available framebuffer strategies in relation to your use case. The right choice can help optimize your hardware cost, i.e. assist you in selecting the minimum required hardware in terms of the amount of RAM for framebuffer(s) and the suitable display interface.

A framebuffer strategy defines how much RAM is used for framebuffers and controls how TouchGFX renders to the RAM. The strategy must match the available RAM and the type of display in the system. TouchGFX offers three different strategies, applicable on display systems with and without GRAM. Below is an overview of the strategies, highlighting their advantages and drawbacks in relation to display systems.

Displays without GRAM

Strategy	Advantages	Drawbacks	Use Cases
Double	No risk of tearing, optimal time for rendering	RAM for 2 framebuffers	High performance UIs
Single	Only RAM for 1 framebuffer	Risk of tearing, suboptimal time for rendering	High - Moderate performance UIs
Partial	Only RAM for less than a framebuffer	Higher risk of tearing, higher CPU load	Moderate - Low performance UIs

Displays with GRAM

Strategy	Advantages	Drawbacks	Use Cases
Double	No risk of tearing, optimal time for rendering	RAM for 2 framebuffers	High performance UIs
Single	Only RAM for 1 framebuffer, no risk of tearing	Suboptimal time for rendering	High - Moderate performance UIs
Partial	Only RAM for less than a framebuffer	Risk of tearing	Moderate - Low performance UIs

Tearing

Tearing is a visual artifact on the display where pixel data from two frames are shown in one screen draw, e.g. the screen has half of an old frame and half of a current one, with a clean horizontal split across (the tear). The location of the tear varies according to timing, it usually jumps all over the place, which can be distracting.

UI Performance

In the general Performance article, you will be introduced to aspects of UI performance, which covers how the individual UI components and there structure impacts performance. In the context of framebuffer strategy we think of:

• High performance, as UIs that uses multiple complex UI components/animations, e.g. Texture Mappers, SVGs, screen transitions
• Moderate performance, as UIs that uses few complex UI components/animations
• Low performance, as UIs that uses no complex UI components/animations

Note

The above examples are not definitive. Keep in mind that the UI performance depend on your hardware and UI design.

Glossary

The following terms are used to describe the different framebuffer strategies.

• Display Controller (DC) - The hardware that reads pixels from memory. Is continuously reading the memory containing pixels. Sometimes referred to as the scanline.
• Display Transfer (DT) - The hardware responsible of transferring pixels from framebuffer memory to GRAM. Is only initiated by the MCU when required. Sometimes referred to as the transferline.
• Framebuffer Write (W) - The rendering of pixels to the framebuffer.

Displays without GRAM

The following demonstrates the working concept of framebuffer strategies on displays without GRAM. Common for all strategies are the use of a Display Controller which continuously reads pixel data directly from a framebuffer.

Double Buffering Strategy

Having two framebuffers allows rendering of the next frame into one framebuffer while the Display Controller scans the other framebuffer. Render time of the next frame is unrestricted by the Display Controller. Swapping framebuffers is blocked until the next frame is ready, meaning no risk of tearing because the Display Controller just scans the current framebuffer once again. The framebuffers are swapped after the Display Controller has scanned the entire framebuffer and the rendering is complete.

Double Buffering Strategy Concept

Single Buffering Strategy

Having one framebuffer allows rendering of the next frame into the same framebuffer as the Display Controller scans from. Render time of the next frame is restricted by the Display Controller. The Display Controller scans continuously, so if writing to the framebuffer takes too long, the Display Controller will collide (catch up) with the writing area and tearing will occur. This is caused by rendering complex UI components.

Single Buffering Strategy Concept

Partial Buffering Strategy

A single partial framebuffer block is used to emulate a full size framebuffer through a Memory Management Unit (MMU). Therefore this strategy is also known as Emulated Framebuffer Strategy.

The partial block acts as a sliding window moving down through the emulated framebuffer, with the phase and speed of the Display Controller.

Having a partial framebuffer block only allows rendering of a small portion of the next frame, because the block is reused multiple times to render the current frame. The reuse of the partial block results in a large number of small rendering operations, which result in higher CPU load. Render time of the next frame is restricted by the Display Controller and the partial block size. The Display Controller scans continuously, so if writing to the partial framebuffer block takes too long for any given region of the emulated framebuffer, the Display Controller will collide (catch up) with the writing area and tearing will occur. This is caused by rendering complex UI components. Compared to the Single Buffering Strategy the risk of tearing is higher because the working area of the Display Controller and framebuffer rendering is much smaller.

Partial Buffering Strategy Concept

Note

This strategy is only available on MCUs with a STM32 Chrom-GRC (GFXMMU)

Displays with GRAM

The following demonstrates the working concept of framebuffer strategies on GRAM displays. Common for all strategies are the use of a Display Interface used for transferring pixel data from a framebuffer to the GRAM on the display.

Double Buffering Strategy

Having two framebuffers allows rendering of the next frame into one framebuffer while the pixels are transferred to GRAM from the other. Render time of the next frame is unrestricted by the Display Transfer. Display transfers are only initiated when the next frame is ready, meaning no risk of tearing because the Display Controller just scans what is already in GRAM. The framebuffers are swapped after the display transfer and the rendering is complete.

Double Buffering Strategy Concept

Single Buffering Strategy

Having one framebuffer allows rendering of the next frame into the same framebuffer where pixels are transferred to GRAM. Render time of the next frame is restricted by the Display Transfer bandwidth. Display transfers are only initiated when the next frame is ready, meaning no risk of tearing because the Display Controller just scans what is already in GRAM. Rendering of the next frame cannot complete before the corresponding area to update has been transferred to GRAM.

Single Buffering Strategy Concept

Partial Buffering Strategy

One or more partial framebuffer blocks are used to emulate a full size framebuffer.

The partial blocks are reused to render all parts of the current frame that needs to be updated. When a block is rendered it can be transferred to GRAM and used for subsequent rendering.

To minimize the risk of tearing we strive to have the largest margin between GRAM being updated by the Display Transfer and the Display Controller scanline. This is done be having the transferline behind the scanline, which means that we can only render the current frame and not begin rendering the next frame. Render time of the current frame depends on the number of partial blocks defined and the time it takes to transfer each block. This means that we are allowed to render a block that is ahead of the Display Controller scanline if a block is available. If rendering and transferring of all the dirty areas of the current frame takes longer than the Display Controller its scanline can wrap around and catch the transferline, resulting in tearing. This is caused by rendering complex UI components and/or transferring too many pixels.

Partial Buffering Strategy Concept

Getting Started with Framebuffer Strategies

In the following section we will show common hardware setups and point to scenarios on how to use framebuffer strategies on various hardware setups.

Further reading

See article Buffering Strategies & Location on how to configure a framebuffer strategy through the TouchGFX Generator.

Displays with GRAM

This display type has a dedicated RAM buffer with the same size as the display, i.e. a full size framebuffer.

Display with GRAM

The interfaces for this type of display are:

• FMC
• SPI
• DSI (Command Mode)

Scenarios demonstrating the use of these interfaces can be found here:

• FMC Display Interface
• SPI Display Interface
• DSI (Command Mode) Display Interface

Displays without GRAM

This display type doesn't have a dedicated RAM buffer.

Display without GRAM

The interfaces for this type of display are:

• LTDC
• DSI (Video Mode)

Scenarios demonstrating the use of these interfaces can be found here:

• LTDC Display Interface
• MIPI-DSI Video Mode

Further reading

The STM32 LTDC display controller document has further details on framebuffers.