Connect lvgl and epdiy directly, any suggestion?

[lanistor]

Introduce the problem

Combining lvgl and epdiy, we facing a problem: the pixel need to convert to color of epaper (16 grayscale colors, 0~15), when using set_px_cb, the painting will be very slow, it increases the time consumption by 2.0~2.5 times, here is the test result: https://github.com/lvgl/lvgl/issues/3921#issuecomment-1407588802.

Proposal

I think if lvgl has a color like lv_color4_t, the painting will not need to call set_px_cb before flush_cb, thus will increase the painting speed a lot.

I'm going to resolve this problem, add a lv_color4_t to lvgl ? Is there a better way to resolve this problem?

https://github.com/lvgl/lvgl/issues/5294

[martinberlin]

Cool will try this when I find some time. Leaving this open for a while so I don't forget!

[lanistor]

Cool will try this when I find some time. Leaving this open for a while so I don't forget!

I don't know if it's the best way, let me test for a few days.

[martinberlin]

@lanistor how is going on with this?

maybe you can make an LVGL fork and we can link your efforts from here? Because I’m also interested on this topic

[vroland]

@lanistor Another idea: Afaik LVGL also supports grayscale (8 bit). You could use two buffers, one as a draw buffer for LVGL and another that you transfer into then calling flush_cb. Since there you don't need to care about rotation / bounds checking it should be faster, even more so when using the S3 vector instructions. Not sure if it's worth the extra work and memory consumption, just throwing the idea out there.

[martinberlin]

I'd like both ideas very much. @lanistor please make a fork of LVGL so I can follow our progress. Soon I will make myself a new touch Kit and try again now that we have a faster way to send the framebuffer with S3. The only problem I see with LVGL is that it updates always small parts of the display, which makes of course total sense, but is not optimized for epaper so using it a lot in a fixed UX generates some ghosting. Someone has to find a clever way to balance that otherwise is very hard to make usable interfaces

[lanistor]

@lanistor Another idea: Afaik LVGL also supports grayscale (8 bit). You could use two buffers, one as a draw buffer for LVGL and another that you transfer into then calling flush_cb. Since there you don't need to care about rotation / bounds checking it should be faster, even more so when using the S3 vector instructions. Not sure if it's worth the extra work and memory consumption, just throwing the idea out there.

I didn't find the grayscale (8 bit), what's it name?

[martinberlin]

Hello Lanistor, any update in this field?

[lanistor]

Sorry, i havn't start on it yet, for Busying in mass production of products.

[martinberlin]

It’s no problem I’m also busy in another things. But I have actually the same needs for a client, maybe we can help each other on this one

[martinberlin]

Lanistor we 've been working into LVGL also for a client needs using a v7 clone. You can follow our efforts here: https://github.com/martinberlin/lv_port_esp32-epaper/ Target is an Eink Kaleido 6" display. But it could be easily modified to support other displays.

Some of our experiences optimizing time for LVGL resumed in a few sentences:

• Use only DU mode (Sorry no grayscales if you want to go fast)

• Do not update chunks all the time like if it was a fast parallel TFT. Only push the whole update when the updates in the display are complete

  if (lv_disp_flush_is_last(drv)) { // only send to e-paper when complete
      // DEFINE update_area
      epd_hl_update_area(&hl, updateMode, temperature, update_area); }

  Trying to document this slowly here: https://github.com/martinberlin/lv_port_esp32-epaper/wiki/epdiy-v7 Please share your thoughts also and be welcomed to try our repository.

[lanistor]

Lanistor we 've been working into LVGL also for a client needs using a v7 clone. You can follow our efforts here: https://github.com/martinberlin/lv_port_esp32-epaper/ Target is an Eink Kaleido 6" display. But it could be easily modified to support other displays.

Some of our experiences optimizing time for LVGL resumed in a few sentences:

• Use only DU mode (Sorry no grayscales if you want to go fast)
• Do not update chunks all the time like if it was a fast parallel TFT. Only push the whole update when the updates in the display are complete

  if (lv_disp_flush_is_last(drv)) { // only send to e-paper when complete
      // DEFINE update_area
      epd_hl_update_area(&hl, updateMode, temperature, update_area); //update_area

}

Trying to document this slowly here:
https://github.com/martinberlin/lv_port_esp32-epaper/wiki/epdiy-v7 Please share your thoughts also and be welcomed to try our repository.

Got it, thanks a lot. I found another way for optimizing: rendering screen on cpu that does not contain ui thread, this speed up a lot.

[martinberlin]

I found another way for optimizing: rendering screen on cpu that does not contain ui thread, this speed up a lot.

That sounds very interesting. When you meant rendering screen on CPU do you mean core of the MCU? Can you please give some more details and share what was the change to make that happen?

[lanistor]

I found another way for optimizing: rendering screen on cpu that does not contain ui thread, this speed up a lot.

That sounds very interesting. When you meant rendering screen on CPU do you mean core of the MCU? Can you please give some more details and share what was the change to make that happen?

Yeah, here is the demo code : https://github.com/flickerlist/lvgl_epaper_drivers/blob/release/monochrome/lvgl_tft/epdiy_epaper.cpp.

I start a new thread on core 1 (while ui thread on core 0), and i will suspend the thread when no rendering, to save power.

It need well adapted to business logic, the thread's resume, suspend must called in ui thread, because there will be thread synchronization issues. In my business, i run epdiy_check_pause in ui thread's loop checking,