ili9488: Start updating to new display port interface

[C47D]

No description provided.

[C47D]

I've been trying to remember why do we allocate memory in the flush callback, and I think it's because this particular display can only work with RGB666 in SPI mode (I might be wrong tho).

So I guess we could try to use another color depth, one that doesn't require any memory allocation?

[JojoS62]

lvgl/lvgl#2737 (comment)

[C47D]

@JojoS62 Thanks for pointing that issue out, my intention of avoiding the memory allocation is to make the driver as "platform" or "mcu" independent as possible. Are you currently using the ILI9488 display controller with higher color depth?

[JojoS62]

I'm following the lvgl development in general, and have looked also how different drivers are implemented.
I haven't used the ILI94xx yet, and I would not use higher resolutions with SPI. I was also not aware that these drivers do not offer RGB565 with SPI, so even more worse. I understand that the ESP32 has not enough pins for parallel interfacing, but then this controller is simply not well suited for such displays. Technically, it can be used, but for the cost of speed. There is a nice table of different controllers/displays that are supported with ESP, maybe it can be extended by a note or measurements of performance.
For this driver, I would also try to use 32 bit color depth and reduce to 18 bit in the flush, I guess this is a better solution than frequent memory allocations. I don't know how these are implemented on the ESP, but in general, memory allocations in a RTOS require some locking to avoid concurrent allocations. So this may slow down the driver also.

[C47D]

I would not use higher resolutions with SPI. I was also not aware that these drivers do not offer RGB565 with SPI, so even more worse.

Yup, I agree on this.

There is a nice table of different controllers/displays that are supported with ESP, maybe it can be extended by a note or measurements of performance.

Made that table long ago, I will add a column with basic notes. Maybe it's better to open a new issue to address this. See #139

For this driver, I would also try to use 32 bit color depth and reduce to 18 bit in the flush, I guess this is a better solution than frequent memory allocations.

Will try this option, but it's been a while since I write a driver for LVGL 😸

Thanks for the suggestions

[tore-espressif]

Yep, it seems that ILI9488 is not a good place to start with refactoring 🤷
Related: #103 (comment)

[C47D]

Well, the refactoring has been going for some time, this might be the third display that is updated. But I agree, this controller is a special case.

Can we merge it as it is, and leave the display optimization for another request?