Skip to main content
Version: 4.16

General UI Component Performance

This section describes the performance of general TouchGFX rendering operations used by most UI components.

Image Drawing#

Image drawing is one of the most essential drawing operations in TouchGFX, as almost all UI components to some extent rely on drawing one or more images. The ability of your system to draw images in a fast and effective way is therefore often very important. There are a lot of factors that influence the performance of image drawing. However, on almost all hardware setups, TouchGFX image drawing is considered a fast operation compared to other drawing operations.

Hardware support for data copy#

TouchGFX stores the image data uncompressed in the selected image format (e.g. RGB565, L8, ARGB8888). The advantage of the uncompressed format is that it allows TouchGFX, in most cases, to use the image directly and transfer it unmodified to the framebuffer. If the MCU has a DMA, this can and should be used for the memory copy, as this speeds up the transfer and minimizes the MCU load.

One limitation to this approach is if the image format includes an alpha channel. Here a normal DMA transfer cannot be used since the MCU needs to perform pixel blending of the image data with framebuffer pixels. However, if you are using an STM32 with graphics acceleration like Chrom-ART / DMA2D, you can utilize the DMA for these types of images as well. Here the DMA is not only capable of copying data, but actually does a copy and blending operation in one go, thereby improving speed and lowering the MCU load considerably.

Image format#

The image format has an impact on the image drawing performance as well, depending on the hardware support you have. A rule of thumb is, that the less data you have to transfer, the faster you can do it. So transfering an RGB565 image compared to a similar RGB888 will be faster in most cases, since an RGB565 image is two thirds the size of the equivalent RGB888 image.

Access to the Image data#

The time needed to access the image data is very important, since this will be accessed each time the image is rendered. The image data can be stored in different hardware locations, with different access times, in a TouchGFX application.

Image data locationDescription
External FlashThe advantage of external flash is its low cost and the size, which is often quite large, allowing you to have a lot of images in your application. However, access time varies a lot, but choosing QSPI or alternatives like it, will give you a high throughput, resulting in a significant boost to the image drawing performance.
External RAMIn some cases you might need to cache your images in External RAM. This is often the case when you are forced to use non-memory mapped flash (e.g. NAND, EMMC) which cannot be used directly for image rendering in TouchGFX. In this case the access to the external RAM is essential for the performance of image drawing in your application.
Internal FlashIn some cases you can store some or all of your images in internal flash, even though the storage space here is very limited. Access is very fast, so if you have some images that are essential for an animation and performance is an issue (e.g. if it is used by a TextureMapper) it might be worth trying to store it in internal flash if possible.
Internal RAMIn very rare cases, you will render images from the internal RAM. The storage space is very limited but the access time is very fast, so images stored here (using TouchGFX Image Caching) will be rendered very fast.

Access to the framebuffer#

Rendering an image will always end up in an update to the framebuffer. If the image includes an alpha channel, you will not only write, but also read pixel data in the framebuffer to perform the actual blending. Therefore, the read/write access time to the RAM you are using for storing the framebuffer is key to have a good image drawing performance.

Image resolution#

Since the data that needs to be transfered is proportional to the resolution of the image, the image resolution naturally has an effect on the image drawing operation.

Transparency#

The opacity of an image has an effect on the rendering time for an image. An image with alpha will have a longer rendering time than an image without due to the fact that it will have to be blended with the framebuffer. Therefore, a blending operation has to read from the framebuffer, whereas a solid image can simply overwrite data in the framebuffer. This is the case even if you have hardware acceleration. The ratio between rendering solid and semi-transparent images may, however, vary from one setup to another.

MCU Drawing#

Some widgets rely on direct framebuffer manipulation. This approach performs one or more calculations for each pixel in the invalidated area, then updates the pixel in the framebuffer. This is a rather slow operation, especially if the calculation for each pixel is complex.

The MCU processing power is essential if your MCU drawing is performing a lot of calcuations. Access to the framebuffer (access to either internal or external RAM) will also have an impact since writing (and possibly reading) the framebuffer data is done per pixel in the invalidated area.

Canvas Widgets#

Canvas widgets are a special type of TouchGFX widget used for drawing anti-aliased geometric shapes. They are typically quite complex and thus potentially fairly slow to render.

The rendering time is linear to the size of the invalidated part of the geometric shape.

Canvas widgets requires a memory block to store intermediate calcuation results. The size and performance impact of this is described in the canvas widgets section.

Tip
Most of the standard TouchGFX canvas widgets, like Circle, have update methods that will only invalidate the changed part of the widget. So if you are updating a Circle for example, use circle::updateArc(...), which will not invalidate the entire circle but only the changed part. Be sure to use these kind of operations for optimal performance.

Texts#

Text rendering depends on image drawing, as all the used characters are transformed into images as described in the text section. The images are in A4 format which is basically a 4 bit alpha value for each of the pixels in the image. If you apply a color to this pattern, you will have an anti-aliased image of a character.

Since text rendering is a set of image drawing operations, one for each character, the performance characteristics for image drawing applies to text rendering as well, including performance improvements using hardware acceleration like Chrom-ART / DMA2D.