Welcome to the Altia Developer Blog Series! These posts are written by our very own GUI experts to present design ideas and smart solutions for developing and deploying embedded user interfaces with Altia Design, our UI editor, and Altia DeepScreen, our automatic graphics code generator.
Be sure to sign up for our newsletter to get this content delivered directly to you!
Reducing RAM usage for a miniGL target
Altia miniGL is an Altia DeepScreen architecture implementation that has been used alongside things like OpenVG and software rendering to generate designs for less capable, resource-restricted targets or environments.
Altia miniGL code is already very optimized in terms of RAM consumption, but if you are still looking for ways to reduce RAM, here are some suggestions worth examining.
Avoid unnecessary objects
Altia miniGL packs data very efficiently, but there are some design choices that can further enhance the effectiveness of this optimization. The Built-In Animations and Image Objects use File System options from the code generation screen will increase the amount of RAM used. These options force your DeepScreen code to allow for more variability, thus reducing the optimization because the range of the data is unknown. This same effect occurs when using Snapshot Objects. Avoid these objects or code generation options if you do not need them.
Generally, the next candidates for RAM reduction are Text I/O objects. These can be trimmed by checking that length of every object so that it only consumes the minimum required amount of RAM. You can adjust your code generation setting max text string length (static memory) to the length in characters of the longest possible Text I/O. This can also save room in the internal data arrays as well. If any of the Text I/Os in these arrays are not addressed by a Language Object or by the logic, they can be changed to static labels. Static labels are stored on ROM instead of RAM.
Same images, same name
If your design contains multiple references to the same image source file, make sure that all the animations where this image is used share the same name. If you copy and paste an image object, the name is incremented automatically. You can see an example of this below.
This can be prevented by appending _global to the animation variable name and is also demonstrated below.
Now, all these different objects will load and reference the same image instance in RAM. This enables embedded wizardry like reducing a solid color background image to a single column of pixels copied for the width of the display. This will use the minimum amount of RAM versus loading an entire image. This must be done alongside unselecting the Image Objects use File System option under code generation. Now the same image data is referenced by however many image animations share a name in the generated binary file.
It’s best to test
Lastly, remember to test and compare the results of all methods mentioned in this post. Estimating RAM usage is highly system dependent and the most reliable answers to your questions will be to generate and compile code for your device and design. Similar looking designs can differ greatly in RAM usage due to design implementation. Moreover, the same design can have radically different memory usages on different hardware. For example, some devices can reference the image data directly out of Flash and put it into the framebuffer. But other devices may need to have RAM copies of images to render them.
Just remember, there are so many variables at play on an embedded platform, that estimates of a project’s total RAM usage is likely to be inaccurate. There is no better way to find your system’s RAM usage than running your design on your hardware – and Altia makes it easy to do just that.
Want to learn more about Altia code generation? Request a live demo with us today!