Actually, lv_theme_default_init creates some styles when the default styles are really not working. E.g. for lv_led or lv_sw.
There is no way to set back the non-theme styles once you have created an object with an active theme. But lv_theme_default should give a “very default” but slightly better result.
Above is a dump from the concerned section of a linker map file, the last hex numeric value is the ram allocated to to the respective modules.
As only one theme can be active at any given instant, to me it seems wastefull to statically allocate the memory this way.
Would not be better to have an option to at least allocate these memories to a heap (either LVGL’s, or compiler default) only once they are needed. Or have it statically allocated to the largest amount needed.
In either case at most 2 of the memories would need to exist concurrently if there is no other option.
I pasted the incorect section from the map file above, but my main point is the same,
.bss zero 0x2002'3b64 0xf8c lv_theme_alien.o [1]
.bss zero 0x2002'4af0 0x480 lv_theme_default.o [1]
.bss zero 0x2002'4f70 0x1b0 lv_theme_material.o [1]
.bss zero 0x2002'5120 0xf08 lv_theme_material.o [1]
.bss zero 0x2002'6028 0x574 lv_theme_mono.o [1]
.bss zero 0x2002'659c 0xf8c lv_theme_nemo.o [1]
.bss zero 0x2002'7528 0xdac lv_theme_night.o [1]
.bss zero 0x2002'82d4 0x1b0 lv_theme_zen.o [1]
.bss zero 0x2002'8484 0xf80 lv_theme_zen.o [1]
If my calcs are correct that totals 0x58a0 (22K…) bytes, where the largest of them lv_theme_material require a little over 4KB on its own. This means around 18KB is taken out from what the system has availalbe ALL of the time, (it would be better, although not optimal if this were only when required) and on most embedded systems this is a lot to have laying around just in case a configuration setting is changed on the fly.
Surely there is a more efficient way of using availalble memory when all themes are included (and referenced) in the build ?
There are use cases when more themes need to be kept alive, e.g. when you modify the themes manually and change them as “live update”. However, with some updates, the themes’ extra data (custom styles) really can be dynamically allocated and freed by a de-init function.
Are you referring to situations like the lv_test_theme_2 in the examples repo ?
If so it could be rewritten such that at any given instant only two and not ALL themes need to be persistent while changes are being made.
Not exactly. I mean, for example, the user inits the material theme, changes some fonts and colors. And after that inits the night theme and also modifies it. It’s possible that the user wants to keep both modified themes in RAM.
An explicit deinit function would provide enough flexibility IMO.