Practical Tips for Memory Management
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 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.
Available under certain Qt licenses.
Find out more.