LVGL and epdiy. Is that even possible?

[martinberlin]

Two years ago I tried adding an epdiy driver in LVGL:
https://github.com/martinberlin/lvgl_epaper_drivers/blob/master/lvgl_tft/epdiy_epaper_mono.cpp

This works and I even manage to add support for some touch models like paperwhite1, with Dario that was helping on reverse engineering, like paperwhite 1: TMA445 (Cypress)

epdiy test in Kindle paperwhite1

I know @lanistor also tried this. And the question is:
Is it worth it?
Is the lag that epaper imposes this slow Frames-per-seconds even qualified to do LVGL?

And the answer varies. I would say that using a 1024768 ED60** it might work. Using @vroland last effort on acceleration using vector-extension-experimentation branch the display delivers this log:

epdiy: Using optimized vector implementation on the ESP32-S3, only 1k of 65536 LUT in use!
epdiy: diff: 38ms, draw: 76ms, buffer update: 5ms, total: 119ms

That means the epdiy side takes 120ms to make the diff, draw and send the buffer to the Eink.
But that means that really we could have 1000/120 about 8 frames per second?
Not really because once the epaper receives the buffer takes also about 100 ms (Or less depending the Waveform you use) and Kindle does it like double faster... plus, also LVGL itself takes it's own time to "draw" your widgets and UX.
Unless someone proves me wrong that makes it go at least half of that frame rate, let's say in best case scenario: 4 frames-per-second.

Your mileage might vary. I would say to design a very simple UX it could be done with LVGL.
But if you just need a couple of buttons, like let's say you design your own e-reader Kindle S3 clone, then NO. Just make your own touch detection and tools to draw the UX. You don't need the overhead of LVGL in many cases.

So you see the contradiction here?
Very simple UX -> You really don't need LVGL.
Complex UX -> Yes you do, but can you live with 3 or 4 FPS?

[lanistor]

Actually, with lvgl, i only got 1 FPS for 1024*758 fullscreen rendering.

[martinberlin]

Using v7 and latest vector branch, still a pull-request, and setting the display clock to 30 Mhz you should go faster than that.
All to the maximum speed: CPU to 240 Mhz, PSRAM to 120 Mhz, line-cache to 64 bytes just as is documented in the wiki

[martinberlin]

Important point to have faster frame-rate. Make sure only to flush to the slow display when every part is ready checking with lv_disp_flush_is_last

/* Required by LVGL. Sends the color_map to the screen with a partial update  */
void epdiy_flush(lv_disp_drv_t *drv, const lv_area_t *area, lv_color_t *color_map)
{
  static int x1 = 65535, y1 = 65535, x2 = -1, y2 = -1;
  ++flushcalls;
  uint16_t w = lv_area_get_width(area);
  uint16_t h = lv_area_get_height(area);
  EpdRect update_area = {
      .x = (uint16_t)area->x1,  .y = (uint16_t)area->y1,
      .width = w,  .height = h};
  // capture the upper left and lower right corners
  if (area->x1 < x1)
    x1 = area->x1;
  if (area->y1 < y1)
    y1 = area->y1;
  if (area->x2 > x2)
    x2 = area->x2;
  if (area->y2 > y2)
    y2 = area->y2;
  uint8_t *buf = (uint8_t *)color_map;
  // Check this function in the repository
  buf_copy_to_framebuffer(update_area, buf);
  
  if (lv_disp_flush_is_last(drv))
  { // only send to e-paper when complete
    update_area.x = x1;
    update_area.y = y1;
    update_area.width = (x2 - x1) + 1;
    update_area.height = (y2 - y1) + 1;
    epd_hl_update_area(&hl, updateMode, temperature, update_area); // update_area
    x1 = y1 = 65535;
    x2 = y2 = -1; // reset update boundary
  }
  // printf("epdiy_flush %d x:%d y:%d w:%d h:%d\n", flushcalls,(uint16_t)area->x1,(uint16_t)area->y1,w,h);
  /* Inform the graphics library that you are ready with the flushing */
  lv_disp_flush_ready(drv);
}

[martinberlin]

Alternative library that could be nice to test:
UGFX official Repository
https://git.ugfx.io/uGFX/ugfx

NOTE: There are no drivers so we should add an epdiy based one. But I registered in the Forum and it seems to be a nice community around it. Might be worth a try!
And searching in GitHub they come some ESP32 & SMT32 projects. There are also some preview videos

[martinberlin]

New update achieved today @lanistor @vroland and any other interested party:
https://www.youtube.com/watch?v=x5pLe3q8ObU&t=1s LVGL upgraded to 9 and trying to speed up the drawing part.

At this point is a fully working User Interface capable PCB. WiKi explanation to try it here: https://github.com/martinberlin/lv_port_esp32-epaper/wiki/LVGL-9.0

NOTE: Touch only works with TMA340 (The link that I sent to those interested) with a different version like TMA445 it won't work for now my driver even if it has the same pin-out. This is because it probably needs a different initialization.

UPDATE: In this other Discussion topic I'm asking about the possibility to have a monochrome framebuffer. Maybe that will speed things up!

[lanistor]

Cool !!
Rendering speed seems to have improved a lot.
I saw you still using LVGL, but v9.0. What did you do to improve the speed?

[martinberlin]

Basically v7 PCB and latest LVGL.
Display clocked 28 MHz and RGB332 that is later converted to 4bpp epdiy framebuffer. That part is where there is still room to improve!
You should test this with v7 and a Kindle display with touch

[lanistor]

How to change the Display clocked to 28 MHz?

[martinberlin]

I'm using v7. You can edit the display clock in displays.c (struct property .bus_speed )