Is there a way of de-initing themes ?
In other words, get themes behaviour back to as it was prior to calling any of the lv_theme_xx_init functions.
IE this would be as if LV_THEME_LIVE_UPDATE as well as all LV_USE_THEME_XX are defined as 0 in lv_conf.h
What MCU/Processor/Board and compiler are you using?
General question, relivant to any platform.
What do you want to achieve?
As per description above
What have you tried so far?
Nothing yet, no idea on how to achieve.
lv_theme_default_init. The default theme, if I recall correctly, is equivalent to not initializing a theme at all.
lv_theme_default_init creates some styles when the default styles are really not working. E.g. for
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.
Further to themes, specifically read/write memory useage.
With LV_THEME_LIVE_UPDATE defined as 1. And referencing all themes
.text ro code 0x4'1dec 0x153a lv_theme_alien.o 
.text ro code 0x4'3328 0x722 lv_theme_default.o 
.text ro code 0x4'3a4c 0x1372 lv_theme_material.o 
.text ro code 0x4'4dc0 0x552 lv_theme_mono.o 
.text ro code 0x4'5314 0x141a lv_theme_nemo.o 
.text ro code 0x4'6730 0x1140 lv_theme_night.o 
.text ro code 0x4'7870 0x1176 lv_theme_zen.o 
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 
.bss zero 0x2002'4af0 0x480 lv_theme_default.o 
.bss zero 0x2002'4f70 0x1b0 lv_theme_material.o 
.bss zero 0x2002'5120 0xf08 lv_theme_material.o 
.bss zero 0x2002'6028 0x574 lv_theme_mono.o 
.bss zero 0x2002'659c 0xf8c lv_theme_nemo.o 
.bss zero 0x2002'7528 0xdac lv_theme_night.o 
.bss zero 0x2002'82d4 0x1b0 lv_theme_zen.o 
.bss zero 0x2002'8484 0xf80 lv_theme_zen.o 
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 ?
That’s a good idea!
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.
I’ve added it to the TODO list of v6.1.
Thanks, I am pleased that you see it that way
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.
deinit function would provide enough flexibility IMO.