Very slow full screen animations on ESP32-8048S043C LCD module.

Zer0-bit commented 8 months ago

Carefully written Issues are more likely to be given priority. 丁寧に記述された報告は優先して対応される可能性が高くなります。

Environment ( 実行環境 )

MCU or Board name: ESP32-8048S043C
Panel Driver IC: ILI9485
Bus type: Parallel16
LovyanGFX version: latest develop
FrameWork version: latest ArduinoESP32
Build Environment: PlatformIO
Operating System: Windows & Linux
LCD Unit link: ESP32-8048S043C

Problem Description ( 問題の内容 )

Hello, hope this is an issue on my end rather than a bug but i've not been able to resolve it and decided to ask for the community help if anyone can help. Basically running any full screen refresh on this lcd module results in slow performace, buttons, sliders and any smaller animation performance is very good the only major slowdown happens on full screen animation handling. I've tried to use a different driver library (arduino gfx) and it works fine but the issue is that i can't use that library for the purposes of my project due to task pinning issues on that lib which sends the mcu in a boot loop. Hope someone has some answer to this issue or maybe a fix for the code where i might have missed smth obvious. Also thank you so much for the continuous dedication to the OSS space it wouldn't be such a great space without people like you :)

Expected Behavior ( 期待される動作 )

Full screen animations should not be painfully slow and jittery.

Actual Behavior ( 実際の動作 )

Very slow transitions and full pages refreshes.

Steps to reproduce ( 再現のための前提条件 )

Pull the project form this repo in platformio: https://github.com/Zer0-bit/lvgl-widgets.git
Move the demos folder under .pio/libdeps//lvgl to .pio/libdeps//lvgl/src
Upload the using the pio task to the LCD module.

// If possible, attach a picture of your setup/wiring here.

There is no wiring as the LCD comes into a single unit.

Code to reproduce this issue ( 再現させるためのコード )

Please submit complete source code that can reproduce your problem. あなたの問題を再現できる完全なソースコードを提示してください。

Can pull project straight from the repo and build in pio : https://github.com/Zer0-bit/lvgl-widgets.git

or see the gist below

https://gist.github.com/Zer0-bit/7573ff939662476275c11bb0c5a4f4ac

tobozo commented 8 months ago

hi,

where is the LVGL configuration file? it seems to be missing from the platformio source tree you provided.

see this one as an example

Zer0-bit commented 8 months ago

Hi and thank you for the reply, i'm not using a lvgl_conf to pass the necessary defines but instead passing them via the platformio configuration file, you can see them here https://github.com/Zer0-bit/lvgl-widgets/blob/3b684973800c7e43b5cb8de866d95b7151a4023e/platformio.ini#L16-L44

lovyan03 commented 8 months ago

This is not a defect but a configuration issue. When using the RGB parallel LCD output of the ESP32S3, the operating performance depends on the performance of PSRAM, the frame buffer. Please review the definition in platformio.ini so that PSRAM operates faster.

[env:lolin_s3]
platform = espressif32
board = lolin_s3
board_build.flash_mode = qio
board_build.arduino.memory_type = qio_opi

lyrew0lf commented 8 months ago

Quite sure that unit has Octal PSRAM, and could run at 120MHz with experimental features turned on. Should increase performance substantially when configured as such.

On Fri, Sep 1, 2023 at 8:00 AM lovyan03 @.***> wrote:

This is not a defect but a configuration issue. When using the RGB parallel LCD output of the ESP32S3, the operating performance depends on the performance of PSRAM, the frame buffer. Please review the definition in platformio.ini so that PSRAM operates faster.

[env:lolin_s3] platform = espressif32 board = lolin_s3 board_build.flash_mode = qio board_build.arduino.memory_type = qio_opi

— Reply to this email directly, view it on GitHub https://github.com/lovyan03/LovyanGFX/issues/444#issuecomment-1701926351, or unsubscribe https://github.com/notifications/unsubscribe-auth/BBTCZD4DNMT4MNTROSVMIMLXYEQSXANCNFSM6AAAAAA4FYJZCU . You are receiving this because you are subscribed to this thread.Message ID: @.***>

Zer0-bit commented 8 months ago

I have done this but the performance hasn't changed at all, the screen transitions are happening like a 1fps slideshow.

The interesting bit is that same config be it with or without the board parameters you suggested above works absolutely fine using Arduino GFX which has led me to the idea that it might be a rendering inefficiency somewhere in the code maybe.

lovyan03 commented 8 months ago

If there is any inefficiency, it is not letting LVGL generate swapped images.

Set LV_COLOR_16_SWAP to 1.
Cast data to (lgfx::swap565_t*) on transfer with my_disp_flush.

Zer0-bit commented 8 months ago

If there is any inefficiency, it is not letting LVGL generate swapped images.

Set LV_COLOR_16_SWAP to 1.

Cast data to (lgfx::swap565_t*) on transfer with my_disp_flush.

Sadly this didn't change the behaviour either

lovyan03 commented 8 months ago

あなたのコードを読みました。 LVGLの準備の仕方が ArduinoGFX向けのコードと LovyanGFX向けのコードで全く別のものになっていますね。

LVGLの動作条件を揃えてから比較してください。

lovyan03 commented 8 months ago

lv_disp_draw_buf_init に与えているバッファのサイズが LGFX向けのものは極端に小さくなっています。この条件で比較されたなら性能は当然低くなるでしょう。

Zer0-bit commented 8 months ago

lv_disp_draw_buf_init The size of the buffer given to LGFX is extremely small. If compared under these conditions, the performance will naturally be lower.

I was actually writing about this as well just now when you replied, i have tried with the same buffer on both and still same results, just to be clear i'm not trying to compare lovyan gfx to arduino gfx, i'm merely using the arduino gfx lib as a criteria which shows the screen can operate faster, i'm trying to solve this issue for lovyan and to have a solution as this screen is quite popular and so far i've not found a solution making it useable :(

I can provide videos btw showing the behaviour if that can help somehow maybe ?

Edit: i used this buffer i declared in the platformio.ini for both libraries :

-D LV_MEM_SIZE="(64U * 1024U)"

Zer0-bit commented 8 months ago

I also updated the code to reflect my local changes.

lovyan03 commented 8 months ago

これぐらいの性能は出ますけどね。

https://github.com/lovyan03/LovyanGFX/assets/42724151/2873ca8c-ff3a-4dc5-8302-862ea8ae9485

あなたの使い方がおかしいんじゃないですか？

Zer0-bit commented 8 months ago

This is how good it is, though.

WIN_20230901_20_03_31_Pro.mp4 Isn't there something wrong with your usage?

Yeah i never excluded that it's my usage that's wrong i was just trying to understand where to look as i have no idea how display drivers work hence it's harder for me to judge whether the performance issue is related to smth i'm doing or configuring wrong. I'll try and align both libraries better in terms how code is structured, thank you so much for your time, i will update once i have more results plus updated config. Also sorry if i left the impression i'm saying smth is worng with Lovyan GFX, it wasn't my intent at all :)

Zer0-bit commented 8 months ago

Update on above, huge thx to @lovyan03 for helping and literally pointing me towards the direction i was making mistakes, problem has been solved by setting appropriate buffer and buf size in pixel values.

Just not to leave the show without a resolution here are the changes i made outlined below.

Implementation file.

#define MAIN_CONTENT_WIDTH 800
#define MAIN_CONTENT_HEIGHT 420

static lv_color_t *disp_draw_buf_1;  //init buffer1
static lv_color_t *disp_draw_buf_2;  //init buffer2

// assign heap in the PSRAM for both buffers
disp_draw_buf_1 = (lv_color_t *)heap_caps_malloc(sizeof(lv_color_t) * MAIN_CONTENT_WIDTH * MAIN_CONTENT_HEIGHT/12 , MALLOC_CAP_SPIRAM | MALLOC_CAP_8BIT);
disp_draw_buf_2 = (lv_color_t *)heap_caps_malloc(sizeof(lv_color_t) * MAIN_CONTENT_WIDTH * MAIN_CONTENT_HEIGHT/12 , MALLOC_CAP_SPIRAM | MALLOC_CAP_8BIT);

// init driver buffer passing both buffers and the size of buf1 + enough pixels to cover both buffers
lv_disp_draw_buf_init(&draw_buf, disp_draw_buf_1, disp_draw_buf_2, MAIN_CONTENT_WIDTH * MAIN_CONTENT_HEIGHT/12);

In the lgfx_8048S043C.h i changed the below line value from 16000000 to what you see below and everything started working smoothly. cfg.freq_write = 14000000;

lovyan03 / LovyanGFX