WIP: Implements "full color" 16 bit driver for ST7789 and adds ColorBitMap widget & demos

[Troyhy]

Hi

I was inspired from your work and for project that I am planning there is a need for showing "full color" images. How do you feel the direction that I have taken with ST7789_16bit.py driver and ColorBitMap widget. I copied the image_converter from https://github.com/russhughes/st7789py_mpy/blob/master/utils/image_converter.py including the bitmap() function to decode image to frame buffer.

This branch is not very well tested and I do not suggest you REALLY merge this as it is, but I would like to hear your comments.

[peterhinch]

I avoided writing a 16-bit diver for ST7789 because of the 115,200 byte buffer: this is excessive on most microcontroller platforms. My display drivers are primarily intended for use with the three GUI variants. These use limited sets of fixed colors, which means that the 4-bit drivers work well with 1/4 of the buffer size. Further, aside from nano-gui, the GUI itself uses significant amounts of RAM. These drivers are quite heavily optimised for RAM use, and to overcome the performance hit from using a 4-bit buffer.

I may produce an 8-bit version, which would enable color image display as per the gc9a01 driver.

You might be interested in my approach to image display. The approach is to use error diffusion ("dithering") to enable color image display on an 8-bit driver and monochrome image display on a 4-bit driver (16-bit drivers are also supported).

At the moment I think a 16-bit driver for a display of this size is too big, but my view may change as hardware platforms acquire more RAM. Currently I see operation on a Pyboard 1.1 or on Pico V1 as being a benchmark. As platforms with more RAM become the norm, I may move towards widgets that require full color and drivers that support it.

Re the changes to the 4-bit driver, I avoid using symbolic constants like

_ST7789_SWRESET = b"\x01"

because they waste RAM. I agree that there is a cost in readability, but anyone seriously studying a device driver will have the hardware datasheet in front of them, so the cost (IMO) is near zero.

Re your changes to the listbox, I am very keen to implement dynamically changeable content for both listbox and dropdown, and intend to start work on this now. There may be potential issues with list currency and with scrolling, but I will use your code as a starting point and credit you in the code comments.

As a general point, creating a huge PR with multiple unrelated changes makes them hard to review and unlikely to be merged. I would recommend that each PR should be focused on a single clear aim.

[peterhinch]

I've looked at the .set_elements code and it looks good. I'll do some testing and report back.

There should be scope for calling the method from the constructor to reduce duplication: I will do this if the testing goes to plan. Thank you for the contribution.

[Troyhy]

Hi, Thank you for you feedback for 16bit driver. I understand now better what boards you are targeting and why 16b driver is not usable for such targets. We are targeting ESP-32-S3-DevKitC-1 which has 512kb/8Mb of ram and 32Mb of flash.

I am reading trough https://github.com/peterhinch/micropython-nano-gui/blob/master/IMAGE_DISPLAY.md and I need to inspect your approach more. I wish I would seen it earlier. I only saw the monochrome bitmap widget and that was not enough. Blit method seems really much more robust that my approach. You are absolutely right about the _ST7789_ constants, it was way for me to read trough the code and understand what it does while looking trough the ST7789 manual.

And sorry for confusion about ListBox.set_elements. it was not what I wanted to present, just the driver and way to show the image. Sadly I did not create proper PR from that feature alone. I actually saw the .set_elements issue after I had finished my work on this current PR.

Thank you for you feedback, I gained valuable info how to continue with my implementation. I think we can close this PR.

[peterhinch]

There is no confusion about .set_elements: it's a valid approach to dynamically changing the listbox contents, and I think your code handles list currency and scrolling correctly (though I haven't yet tested it).

As I said above I am starting work on dynamic contents for listbox and dropdown. There are two main issues:

1. I need to figure out whether the set_elements API is the best approach - I have another possible contender.
2. If I do adopt set_elements I will seek to use its functionality in the constructor to save bytes.

As a general point on MP development, I recommend you watch this short video by Damien. One point he makes is about the RAM used by variable names.

Thanks for the contribution.

[peterhinch]

I have pushed an update which provides for variable element lists for Listbox and Dropdown. The API differs from yours in that it allows the passed element list to be edited in place rather than being replaced in its entirety. I have also taken the opportunity to change the code with the aim of reducing allocation.

[Troyhy]

Looking good :+1: I’ll be hacking more with micro GUI as our project progresses. I watched Damien George's video, and, well, this isn't Python, so I need to unlearn some Python 'best practices.'"