Hi,
Using waveshare 2.1 and 2.8 in 9.2.2. LittleFS Arduino IDE, double buffered
Why does adding image to background from file system (either as image widget or as screen background) slows everything down (to about 6-7fps)
Its still the same region that gets refreshed, same amount of data (in bytes… same rectangle… not full screen). Image is fully decoded from jpg on a disk (jpeg is plain, simple, correct resolution, load fine)
If I add the same image as an asset it doesn’t slowdown
What mean asset? Is this asset image have the same jpeg format or just C image file
Sorry I generate LVGL code from SquareLineStudio … asset is a C image
initial image is set in ui_Screen.c
lv_obj_set_style_bg_image_src( ui_Screen1, &ui_img_big_png, LV_PART_MAIN | LV_STATE_DEFAULT );
I load image from LittleFS using
lv_obj_set_style_bg_image_src(ui_Screen1, “S:/image.jpg”, LV_PART_MAIN | LV_STATE_DEFAULT);
Frame rate initial 27-30fps, CPU around 70% when doing nothing (it checks motion, battery…)
After load 16fps, CPU around 80-85% doing nothing
Works with double buffer, LV_DISPLAY_RENDER_MODE_PARTIAL, wifi
bits from lv_conf.h (LVGL 9.2.2. on Arduino IDE)
#define LV_DEF_REFR_PERIOD 33
#define LV_MEM_SIZE (120 * 1024U)
#define LV_USE_TJPGD 1
Same thing happens on Wavershare ESP32-S2-Touch-LCD-2.1 and 2.8"
Why are you surprised?
Primary you complete miss, that jpg isnt plain… Secodary any FS is indirect mapping vs in flash direct mapped memory image will always slow etc.
Except your design have cache for FS and images decoded, then only first load is slow… As you show your ui img was png, but squareline converty it into raw pixels in flash. No next decoding required result is max speed.
My problem is not temporary slowdown… I’m fine with that…
It is slow from the moment I first loaded the JPG and it does not recover.
I have cache on.
That would indicate there is a problem with decoder.
Maybe start reading this Images (lv_image) - LVGL 9.3 documentation
or better try reply why you use filesystem?
I use file system because I download images from the server
Then when you read up docu, see how much memory you require to cache image WxH . Info from your first 2.1 or 2.8 is unusable . Displays is pixel X pixel size and bytes per pixel data…
You have to mess with the image cache settings in the lv_conf.h file. JPG is also pretty compression heavy, you might consider using PNG instead as this tends to be easier to decode.
The other thing you can do to completely bypass any form of compression is you can convert the image to an LVGL binary image file using the online converter or optionally the Python script included in the LVGL scrips folder
The binary file is a good way to go because there is no decompression needed, the file is able to be incrementally loaded as chunks of the data get used and it requires less in terms of memory use. The downside is the converted images are quite a bit larger than a PNG or a JPG file.
I have images coming in from the server… what I am trying to figure out now is to decode image into memory and feed it from there … because if image is in the memory there is no problem
Also I am battling issues with screen tearing during save to file system … which I also didn’t expect (and this is way over my head too)
the tearing is happening because the network read and the filesystem write IO are blocking calls. You would want to move that work over to the other core on the ESP32 so it would not block LVGL from rendering.
You can also use the lv_display_flush_is_last function to determine if a series of buffer flushes is the last one for an update to the display. I am gathering that you are using a partial frame buffer for LVGL and when you use a partial frame buffer it may take several buffers being rendered when something changes in the UI. Calling that function will allow you to know if the update has been completely sent to the display so you re not stepping in the middle of it when you are performing the download from the server which is a time consuming process.
I managed to optimise LVGL_driver.cpp to redraw on vsync and fix the timing frequencies and the rest of the “exciting” stuff … so at least display is stable and smooth
jpg issue remains whatever I do with cache… looks to me like the file is cached and decoded every frame (…) don’t know …