This topic provides some practical tips for memory management with safety-critical UI elements. These considerations affect both storage and the Qt Safe Renderer Runtime component.

You should note that Qt Safe Renderer Runtime allocates random access memory according to values in SafeRenderer::Constraints. When you optimize memory management, you should optimize the safety-critical assets first and then the constraints.

Avoiding Dynamic SafeText

There are several advantages in using static safety-critical QML types instead of dynamic SafeText:

• SafeText, SafeImage, and SafePicture use compressed data as opposed to dynamic SafeText. Especially dynamic SafeText with big fonts uses lots of memory.
• Static SafeText QML type supports all different glyphs for different writing systems.
• Static SafeText works with translations, unlike dynamic SafeText.

In general, consider using the dynamic SafeText QML type only when it is mandatory, like in speedometer numbers or other unforeseen texts. Instead of dynamic SafeText, you could use limited glyph sets (currently Latin-1).

If your font file takes a too large amount of memory, consider creating a custom .qpf2 file with only the glyphs you need, such as numbers. Even if it is a very error-prone and tedious solution, it is optimal from the memory consumption point of view.

The following layout data demonstrates these arguments. You find the data from Qt Cluster example code under <QSR installation path>/Examples/QtSafeRenderer-<version>/saferenderer/qtcluster/layoutData/DashboardSportForm.

4568 Feb 14 12:05 DashboardSportForm.ui.srl
5608 Feb 14 12:05 Icon_TurnLeft_ON_48x48.srb
5608 Feb 14 12:05 Icon_TurnRight_ON_48x48.srb
2732 Feb 14 12:05 iso_grs_7000_4_0083_48x48_e41e25.srb
1948 Feb 14 12:05 iso_grs_7000_4_0456_48x48_5caa15.srb
2752 Feb 14 12:05 iso_grs_7000_4_1434A_48x48_face20.srb
3272 Feb 14 12:05 iso_grs_7000_4_1555_48x48_face20.srb
2736 Feb 14 12:05 kmText_60x30_ffffff.srb
361564 Feb 14 12:05 lato_72_50.qpf2
7120 Feb 14 12:05 safeText_215x68_face20.srb
81 Feb 14 12:05 speedText.srt
552 Feb 14 12:05 turnleft.sts
552 Feb 14 12:05 turnright.sts

The bitmaps are of size 48x48 on screen and need the memory of just a few kilobytes. The static safeText_215x68_face20.srb (215x68 size) takes still under 10kB (7120 bytes, to be exact). One 72px font Lato takes the majority of the space (362kB) even if there is a need for a character or few.

If you have a few message boxes with different text content, it is wise to use static SafeText instead of dynamic SafeText from both memory consumption and performance point of view. First, dynamic SafeText needs a font file to store glyphs. Additionally, Qt Safe Renderer Runtime must reserve a fixed memory area to render dynamic text during startup time. This area must be the size of the dynamic SafeText's bounding box even if there is a lot of empty space in the box.

Animations

Animations create lots of bitmaps depending on animation duration and the set frames per second target value. If the animated graphics are simple, such as ISO icons, they generally compress efficiently and are not a big concern from a memory consumption point of view.

If the graphics are more natural, then bitmaps probably compress inefficiently because the compression algorithm is a simple Run Length Encoding (RLE) algorithm. It does not work well with left-to-right color gradients where color changes along the x-axis. Also, using natural images like photos are problematic for the algorithm. Animating such graphics results in considerable higher memory consumption when compared to simple graphics with lots of same color. Color gradients from top to bottom compress fine.