Font read/write memory usage

Hi,
Is it possible with the new font system (V6) to place some of the internal data (lv_font_fmt_txt_glyph_dsc_t, unicode_list etc) in constant memory instead of read/write memory or do they all need to be in read/write memory ?

I think it was an oversight during the design. I don’t see a reason why everything (except maybe lv_font_t itself) can’t be const. Have you tried it?

No, I have not and did not wan’t to fiddle with it as it would probably mean needing to change structures in the font handlers which I did not want to do without checking.
Perhaps it could be an optional qualifier similar to LV_ATTRIBUTE_LARGE_CONST which could also be placed in lv_config.h ?

There may or may not be performance implications if they are placed in constant memory. But it would be nice to have the option in read/write memory constrained platforms.

There’s no need for the use of const to be optional. LV_ATTRIBUTE_LARGE_CONST is special because it allows moving especially large constant data to a different section (i.e. external flash).

@puzrin @kisvegabor We should be able to use const for all of the generated font data, correct?

I was able to change all the static instances of structures in the font files (apart from unicode_list_x and lv_font_fmt_txt_dsc_t font_dsc) without any compilation or run time issues. (IE works just fine). This alone reduces the read/write footprint greatly (from between 1.5k to 3.5k dpending on the font down to around 148 bytes).
Then,
in lv_font_t
changed void *dsc to const void *
and in lv_font_fmt_txt_cmap_t
changed unicode_list from uint16_t * to const uint16_t *
and instances in the font files.
This also compiles and runs fine, the end result being only lv_font_t remaining in read/write memory, 20 bytes.
I hope this helps.

https://github.com/littlevgl/lv_font_conv/tree/master/lib/writers/lvgl - here is output generator with templates. Anything can be changed with ease.

I have no idea what should be in C, only reproduced example, provided by @kisvegabor. Feel free to update as you wish. Just make sure tests pass.

I’ve added const to the arrays, updated the font converter tool and the online font converter too.

Please test with the latest master.

I have checked and it works fine.
Just a couple of things,
In master, lv_font_roboto_xx.c:
is,

#include "lvgl/lvgl.h"

Should be,

#include "../../lvgl.h"

Or even,

#ifdef LV_CONF_INCLUDE_SIMPLE
#include "lv_conf.h"
#else
#include "../../lv_conf.h"
#endif

Is there a reason you did not also change the dsc member in lv_font to const void * so that

static lv_font_fmt_txt_dsc_t font_dsc;

also be declared as a const ?

True, updated!

#ifdef LV_CONF_INCLUDE_SIMPLE
#include “lv_conf.h”
#else
#include “…/…/lv_conf.h”
#endif

lvgl.h is always in the lvgl folder so the relative path should work in every case. Besides lv_conf.h is not enough because fonts need other header files too.

Is there a reason you did not also change the dsc member in lv_font to const void * so that

It’s not a purely an internal data structure because it directly goes to lv_font_t. And if somebody uses a custom font (e.g. with freetype) probably he will use a custom font descriptor stored in the RAM.

I think it can still be declared as const. Someone using a custom font in RAM can always cast away the constness if they really need to.

I’ve chosen the “cleaner” way and sacrificed a few bytes of RAM, however, your suggestion is also reasonable. Probably much more user will use the built-in font engine so your suggestion will be beneficial for more people. So I’ve added const to lv_font_fmt_txt_dsc_t too.

I needed to revert it because the the last glyphs are cached in lv_font_fmt_txt_dsc_t and they are not const.

Typo, should be change ?

Thanks, fixed!

If you find similar typos, please send a PR on GitHub.

I need to say that the V6 font system is a huge improvement on V5,

The online font converter still outputs const to lv_font_fmt_txt_dsc_t

It’s mainly @puzrin’s merit! :slight_smile:

Try to refresh with Ctrl+F5. Maybe the old Javascripts are cached.