C

Framebuffer Requirements

Overview

The graphical content of a Qt Quick Ultralite application can be shown on the display by drawing the content onto one or several framebuffers. These framebuffers are then read by the display controller before updating the content displayed.

Each framebuffer is a rectangular grid of pixels representing the application layer. On most platforms, a single fullscreen application layer is used. On platforms that support layers, the application may contain multiple layers that are smaller than the size of the display.

You can use the partial framebuffer strategy to lower memory requirements of your application. See Partial framebuffer for more information.

Color depth property

Apart from the layer's width and height, its color depth determines the memory requirement of the framebuffers. Although Qt Quick Ultralite Core supports several color depth formats, most of the reference platforms use 16 bpp (bits per pixel) or 32 bpp color depth. Support for other color depths could also be added by a custom platform port, implementing all the necessary DrawingEngine APIs.

Although higher color depths provide better image quality, they come with a performance overhead and larger memory requirement.

The pixel formats containing alpha bits are useful in the context of multiple layers. Some of those layers may contain semi-transparent content that must be composed on top of the other layers.

The following tables lists the reference color depths and the corresponding pixel formats:

Color depthPixel formatsColor information
32 bppARGB328 bits of alpha, 8 bits of red, 8 bits of green, 8 bits of blue
RGB328 bits of padding, 8 bits of red, 8 bits of green, 8 bits of blue
24 bppRGB8888 bits of red, 8 bits of green, 8 bits of blue
16 bppARGB44444 bits of alpha, 4 bits of red, 4 bits of green, 4 bits of blue
RGB5655 bits of red, 6 bits of green, 5 bits of blue
8 bppRGB3323 bits of red, 3 bits of green, 2 bits of blue

Framebuffering strategies

Qt Quick Ultralite supports both single and double buffering strategies, offering a choice of better performance over memory usage. The single buffer strategy uses less memory but may come with performance overhead. Whereas the double buffer strategy uses more memory but offers better performance. The availability of these framebuffering strategies vary depending on the platform.

The benefit of using double buffering is that Qt Quick Ultralite can prepare the next frame while the previous frame is being read by the display controller. This ensures that the rendering is completed in time for the next display refresh, offering a consistent frame rate. In addition, it is useful on displays that do not have their own framebuffer memory. Flickering is caused when the framebuffer is being read and drawn at the same time, resulting in partially rendered content on the display.

The drawback of double buffering is that twice the amount of framebuffer memory is required.

Both single and double buffering support partial updates, where Qt Quick Ultralite redraws only the content that has changed. In the case of double buffering, Qt Quick Ultralite redraws the changed areas of the layer in both the current and the previous frame.

Note: Refer to the Supported Features table before deciding on the framebuffering strategy.

Memory usage

The memory usage of a given layer can be computed in the following way:

Memory usage in bytes = width x height x bytes per pixel x number of buffers

The following examples show the memory usage requirements for a few combinations of resolution, color depth, and framebuffering strategy:

Layer resolution (width x height)Color depthFramebuffering strategyMemory usage
800x48032 bppDouble buffering3.07 MB
800x48032 bppSingle buffering1.54 MB
800x48016 bppDouble buffering1.54 MB
800x48016 bppSingle buffering768 KB
480x27232 bppDouble buffering1.04 MB
480x27232 bppSingle buffering522 KB
480x27216 bppDouble buffering522 KB
480x27216 bppSingle buffering261 KB
480x2728 bppDouble buffering261 KB
480x2728 bppSingle buffering131 KB
320x24016 bppSingle buffering150 KB
320x48 (320x240/5) 116 bppPartial buffering30 KB
320x24 (320x240/10) 116 bppPartial buffering15 KB

Note: 1 The resolution of a partial framebuffer is not fixed and it indicates the maximum pixel count of a single partial framebuffer. See Partial framebuffer for more information.

Memory regions

Microcontroller units often have separate volatile memory regions, such as Video RAM (VRAM), Internal SRAM, External SDRAM, and so on. The framebuffers should be placed either in VRAM (if available) or in the fastest volatile memory region (Internal SRAM). However, the Internal SRAM is usually being very small, using an External SDRAM is another option to consider.

Important considerations

  • The reference platform adaptations use double buffering by default. It's possible to use single buffering on these platforms with the following changes:
    • Update the frameBufferingType() function to return Qul::Platform::SingleBuffering.
    • Modify the platform code that statically or dynamically allocates the framebuffers, to allocate a single framebuffer per layer.
    • Modify any platform code that assumes the availability of two framebuffers.
  • Add support for different color depths or screen resolutions on platforms that don't support layers.
    • Change the framebuffer allocation code to adapt to the new memory requirements.
    • Return correct screen resolution from the availableScreens() function.
    • Update the beginFrame() function to return a DrawingDevice instance with the correct width and height.

See also Managing Resources and Improving performance using hardware layers.

Available under certain Qt licenses.
Find out more.