How to increase fps with large resolution screen

hello, experts. I have troubles with large resolution(1920*1080) screen fps issue.

  • for 1920*1080. when I use stress to test, the fps can be 13 - 50 . if I use kepadEncoder to test, the fps can be 50, but when I start to drag the screen, the fps decreases to 7.
  • for 800*600. the situation is much better. fps can be between 40-50.

I am pretty sure I use the double buffering (example 3), and the LV_DISP_DEF_REFR_PERIOD is 20ms. what else shoudl I do to increase the fps?

my hardware is x86, my os is rtems. I am using framebuffer to draw the screen.

while the difference in resolution seems like it is about twice the size It is not. using 24 bit color a resolution of 1920x1080 each frame is 6,220,800 bytes in size. If you are redrawing the entire screen and your target FPS is say 30 then LVGL is going to have to render 186,624,000 bytes of data to the frame buffer every second. Now if we look at 800 x 600 in 24 bit color a single frame is 1,440,000 bytes in size. That’s 75% smaller thn 1920 x 1080. That is pretty significant. a full screen redraw at 30fps is 43,200,000 bytes. That’s a whole lot smaller.

Without knowing the hardware you are using we really are not going to be able to help much. 1920x1080 display is not a display you want to attach to an ESP32, STM32 or an RP2. it is going to require something that has quite a bit more giddy up and also has 2d acceleration. If you are running this on a desktop PC there really isn’t too much in the way of hardware acceleration in LVGL other than using SDL2. I would like to see support in LVGL for hardware rendering for ATI and NVIDIA and possibly others. This is something I have been meaning to bring up to the author.

If you are running on some kind of an MCU you can set the memory the buffers are stored in to use DMA. This will allow the CPU to process other things while the buffer data is being transferred. With resolutions of that size I would recommend using at the very least an RGB interface that is 24 lanes wide. Something better like MIPI would be ideal.

RGB display bus requires redrawing the entire display so you would need a sizeable amount of memory. If you can get the buffer to fit into SRAM that would help because SRAM is quit a bit faster than something that is attached to SPI or the like.

If the display you are using has internal GRAM then double buffering with the buffers set into the DMA area of SRAM is going to give you the single largest bump in speed. Set the buffers to be about 1/10th of the data size for the entire display. WIDTH * HEIGHT * bytes_per_pixel / 10