My flush_cb
is quite standard, in case of ESP32 if you are using the component esp_lcd_panel
it’s quite easy to get it mostly right…
static void Display_lvgl_flush_cb(lv_display_t *disp, const lv_area_t *area, uint8_t *px_map)
{
lv_draw_sw_rgb565_swap(px_map, lv_area_get_size(area));
esp_lcd_panel_handle_t panel_handle = (esp_lcd_panel_handle_t)lv_display_get_user_data(disp);
lvgl_spi_transaction_in_progress = true;
esp_lcd_panel_draw_bitmap(panel_handle, area->x1, area->y1, area->x2+ 1, area->y2+ 1, px_map);
}
What i mean with:
and most of the time the real gains are in the display driver flush_cb
than necessarily on LVGL / User GUI Code
Is that some examples over the internet are in reality very bad examples, from using a single partial buffer, and/or having double buffer but having the flush_cb
to stall the processor while the transfer is done removing the advantages of using double buffer, incorrect driver configuration (specially in SPI LCDs, mostly due to clock settings or lack of DMA utilization). Most of them come directly from manufacturers, but it’s important to realize that most the example code from most manufacturers (chip or boards makers) are only as good as a proof of concept that it “works”, but not necessarily in the most optimal way.
Regarding the logs, i don’t know what kind of information/use you what to get from them, but would say that having the level set to LV_LOG_LEVEL_TRACE
is only required if having serious problems, it generates a lot of info and it’s quite tricky to filter what matters and sometimes the hardware becomes so slow because of all the prints that generates other problems… Typically only use LV_LOG_LEVEL_WARN
and eventually LV_LOG_LEVEL_INFO
if more information is required
The last example you have is more interesting with the LV_LOG_LEVEL_WARN
, it gives you detail that your LV_MEM_SIZE
is too low, since memory allocation has failed, LVGL is trying to allocate a buffer with total size of almost 100KB, it seems that your LV_MEM_SIZE
needs to be way bigger.
These logs are useful, since you can check which file/line have generated the error and then browse the code to check if it possible to better understand the reason, or adding extra logs details. If you have LV_LOG_LEVEL_TRACE
you will get more information, but you need to place the all the logs printed in a text editor to more easily find where the warning lv_draw_buf_create_ex: No memory: 130x190, cf: 16, stride: 520, 98800Byte, lv_draw_buf.c:325
line is, to check the previous logs lines to possibly get some extra details, it’s quite tricky to debug using logs, specially because we don’t know for sure which widget was being refreshed at that time that generated the warning/error, a bit of detective work and/or being able to a have a smaller “example” having the same behaviour…