De-Initing themes


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.

Use lv_theme_default_init. The default theme, if I recall correctly, is equivalent to not initializing a theme at all.

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.

1 Like

Thank you,
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 [1]
  .text              ro code     0x4'3328     0x722  lv_theme_default.o [1]
  .text              ro code     0x4'3a4c    0x1372  lv_theme_material.o [1]
  .text              ro code     0x4'4dc0     0x552  lv_theme_mono.o [1]
  .text              ro code     0x4'5314    0x141a  lv_theme_nemo.o [1]
  .text              ro code     0x4'6730    0x1140  lv_theme_night.o [1]
  .text              ro code     0x4'7870    0x1176  lv_theme_zen.o [1]

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 ?

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.

1 Like

Thanks, I am pleased that you see it that way :wink:

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.