Font Memory Estimation

Question

Hello Team,
we are using IMXRT1170 with Embedded Wizard Platform Package for NXP iMX_RT_VGLite V11.00. Our display resolution is 800x480.
I am working on memory estimation for Fonts for certain Latin(Static & Dynamic texts) & Non-Latin(Static text) languages.
Can you please let me know the method to estimate the Font memory for different languages & sizes.

Thank you,
Kavya,
Bosch.

Answer 1

Hello Kavya,

please let us know which kind of memory you want to estimate regarding font resources: Flash size of the font resources, needed to store the compressed fonts in flash memory or RAM size during runtime, needed to store the uncompressed glyphs loaded into heap memory?

Best regards,

Manfred

Comments

Hello Manfred,

Both the estimates are required.

1. How much flash is need after compressing

2. How much RAM is needed for uncompressed glyphs

Regards,

Kavya

---

Hello Kavya,

fonts are usually stored compressed within the flash memory and loaded dynamically during runtime into the RAM.

1. How much flash is need after compressing

Due to the fact that the font resources are stored compressed, the compression ratio depends on the content. In order to predict the flash size required for font resources, let me recommend to create font resources within a test project and configure them according to your needs (font size, ranges, etc.). Then you can generate code and check the Code Generation Report. There you will find the resulting flash size for dedicated font resources with all your settings.

2. How much RAM is needed for uncompressed glyphs 

All glyphs that are required to draw text are loaded dynamically from the flash into the glyph cache. The size of the glpyh cache can be configured:

Within the file ewconfig.h the width and height of the gylph cache surface can be configured by using the macros EW_MAX_GLYPH_SURFACE_WIDTH and EW_MAX_GLYPH_SURFACE_HEIGHT. This surface stores all glyphs used during text drawing operations. The larger the surface the more glyphs can be reused without needing to decompress or rasterize them again. The absolute minimum values for a certain GUI application are shown in the Memory (RAM) usage window. The resulting RAM usage is EW_MAX_GLYPH_SURFACE_WIDTH * EW_MAX_GLYPH_SURFACE_HEIGHT * 1 byte.

If your system has enough memory, you can keep the default value that we have set in the Build Environment for your taget.

I hope this answers your question.

Best regards,

Manfred

---

Hi Manfred,

Thanks for the info.

I tried the same and I get the RAM usage(uncompressed glyphs) very much lesser compared to the flash usage(compressed glyph). I have used the default value in the Build Environment.

Did I miss something? 

 

 

 

Regards,

Kavya

---

Hi Kavya,

of course, the RAM usage for fonts is much lesser compared to the flash usage. This is the idea of the glpyh cache. Only those glyphs are loaded into the cache which are used for a certain drawing operation. This means, you can store thousands of glyphs within the flash - but only a few of them are loaded into RAM.

If this does not answer your question - please explain your observations more detailed.

Best regards,

Manfred.

---

Hello Manfred,

This helps, thanks. I have few more doubts:

1. I am using a multilingual font. What I observed is, only when a text is used in the application, the font range gets included in the memory.

Does this mean there is an optimization performed for the text views that are used or can I understand that the complete range for all the languages are included in this estimation, once any text is used?

2. I am using a string table for static texts to derive a reduced set of character codes.

My understanding is that, it can be used to generate ranges of the character codes used in the table. Here, what is the importance of the input fields start and end in the generation of font range?

Thanks,

Kavya

---

Hi Kavya,

concerning 1: If you are talking about RAM - yes, only the glyphs that are necessary to draw a certain text within the GUI are loaded into the glyph cache as soon as they are needed. As long as there is enough space within the cache, the loaded glyphs are still within the cache. But in total, the gylph cache size is still as defined within the configuration file.

concerning 2: the start and end fields within the excel sheet template are just to include some default character range (e.g. to include all Latin character codes), to have not too much ranges within your font ranges - or to include all characters that are needed for a certain input field. For example, when the user should insert a network name and password, etc.

Best regards,

Manfred.

---

Hi Manfred, 

Thanks for the explanation. 

Concerning 1: "Only when a text is used in the application, the font range gets included in the memory" in  Code Generation Report. i.e., Flash memory for font is generated in the report only when a text view is added in the application with a certain language, and not just with the font file in the solution?

Concerning 2: My question was specific to multilingual font files. In case I use multiple scripts - Chinese, Japanese, Russian, Latin, etc.. within the same font(i.e., string table contains all these language strings), the start and end range could not be defined in common. So what would be the start and end range here? Or the solution is to use different string tables for different language scripts with their respective ranges?

Thanks,

Kavya

---

Hi,

of course, when there is no text view that is using the font resource, the code generator will remove the entire font resource due to optimization.

The start and end range is just for convenience to include a certain range of character codes. If you don't want to use that, you can leave it empty. Please note that the string table excel sheet is just a template, that you can use or adapt according your needs.

The idea of the start/end range for a default character set is just to add e.g. the ASCII range for basic user inputs, network settings, ... (independent from the currently active language).

Best regards,

Manfred