I noticed that ESP32 port is using double buffering.
Would be possible to use it just to update the areas that need refresh and not update all the buffer every refresh?
I didn’t check for details, I’m wondering is the ESP32 is updating the whole screen every time or if it is possible to optimize and update just the areas that changed.
You can use a double buffer, but you aren’t required to. The same goes for the size of the frame buffer(s), it can be the full screen or not… Typically you’d use a portion (say 10%) of the screen, or whatever memory reservation your MCU has free. I use an ESP32 with two 32KB frame buffers. But lvgl can also run on ESP8266 with as little as one 5 KB frame buffer…
The library already only updates the areas that have changed. If that area is larger than the frame buffer can accommodate then the update gets split up into multiple smaller ones.
1 Like
Thanks for your reply!
ok I noticed that the “doublebuffering” was not what I was expecting.
I found in the source code, “#define DISP_BUF_SIZE (LV_HOR_RES_MAX * 40)”
So it only stores 40 lines for the buffer size…
My main concern is not the RAM usage but the speed so I was checking it there was a way to not copy on every refresh the whole screen buffer frame.
But so, looks that in that case (using a small buffer), it will need to call multiple times the the same draw functions of the GUI? and that could be slower, so its better to have a large buffer?
Have look at this blog post from @kisvegabor about the ESP32 performance. It has a good explanation of the different speed considerations and optimizations.
40 lines of buffer can be plenty, but you can certainly increase that to whatever number works best for your application.
What screen are you using and which interface does it have to the MCU? The size of the buffer is not the only parameter that affects the speed. Littlevgl uses it to draw and refresh just the objects that have actually changed. The whole screen is not rendered each time, only (small) portions of it. In that regard the library is already highly optimized.
These are the different ways that you can configure the display buffer(s). It’s mainly a tradeoff between size and speed.