I migrated an ESP32 project from lvgl 8.3 to 9.1.
I’m using LVGL’s built in implementation of memory management, with 32k of memory reserved for lvgl.
First thing I recognized is that for my application lvgl 9.1 needs approx. 5-6k more memory.
Second thing I recognized is, when using lv_mem_monitor, the total size of memory is not anymore the size allocated, and it changes at runtime.
What MCU/Processor/Board and compiler are you using?
ESP32, PlatformIO
What LVGL version are you using?
9.1
What do you want to achieve?
Understanding the reason for additional memory usage in 9.1.
Understanding the total size in lv_mem_monitor in lvgl 9.1
What have you tried so far?
Migrated ESP32 application from 8.3 to 9.1
Used memory usage reports from lv_mem_monitor
Assured that really the memory requested (32k) is allocated in lv_mem_core_builtin.c
Details
As said, I migrated the application from 8.3 to 9.1
In 8.3, lv_mem_monitor gives me the following numbers:
16596 bytes free (50%)
32768 bytes total
after some creation of objects at runtime (and some have been deleted):
11748 bytes free (35%)
32768 bytes total
In 9.1 I get the following numbers (with exactly the same application):
11112 bytes free (37%)
29668 bytes total
after some creation of objects at runtime (and some have been deleted):
4952 bytes free (17%)
29048 bytes total
Update: and I also get from time to time:
[Error] (7.284, +7284) _lv_inv_area: Asserted at expression: !disp->rendering_in_progress (Invalidate area is not allowed during rendering.) lv_refr.c:257
With 32k memory: very often, after some seconds. With 40k: it takes a little bit longer.
So in lvgl 9 there is (32768-31168)=1600 less total size (although 32k were allocated)
And (6100-4860)=1240 more is used.
Overall 1600+1240=2840 more memory needed.
In bigger examples it’s even worse.
Applications where you already have been at the limit in LVGL 8, are now over the limit in LVGL 9.
In the meantime, I did some measurements with different UIs I am using.
Summarized, my measurements tell me that LVGL 9 needs 33% more memory than version 8 (when I compare the free memory). @kisvegabor From what was changed in v9, was this to be expected? Or is it worth to have a closer look at it?
What is causing the largest amount of additional memory consumption is lv_colot_t no longer being a union and the files in that union being defined based on the color depth. Having it that way led to a lot of issues with images and what have you. So now all colors in LVGL are 32 bit and only get converted down in size when the rendering is taking place.
Thanks @kdschlosser for your answer.
We are not only talking about images, right? I removed all “lv_image_create()” from my code, and the result almost stays the same. So more or less all widgets are affected from this change, right?
I understand that sometimes such changes are necessary. But at least for the ESP32 this is really crucial. If you have WiFi and bluetooth activated on an ESP32, there is not much memory left. Only for less than 10 tabs (320x240 screen size).
Finally I ended up in dynamically creating and deletion of tabs at runtime. Only with that it is possible to have an application on an ESP32 (with WiFi and bluetooth) with a somewhat larger number of tabs. But this is not straightforward and most likely out of reach for a lot hobby developers.
With LVGL 8 32k of memory were enough for my application. With LVGL 9 44k are needed. That’s really a significant increase.
If there is nothing we can do about it, than at least we should be aware of that ESP32 applications which were already at the limit will definitely run into problems.
Addendum: if lvgl is running out of memory, with default setting LV_LOG_LEVEL_WARN you will not be informed about it. Application simply stops to work. You need to set LV_LOG_LEVEL_INFO. I took me some time to find this. Others might struggle with it as well. Shouldn’t it be LV_LOG_LEVEL_ERROR? Is running out of memory not an error?
