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 the 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:

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.

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:

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.