framebuf: Support drawing text at different sizes
I'm increasingly making little widgets with MicroPython that use small OLED displays to present information to the user. The text support in FrameBuffer() is great, but it's limited to the built-in 8-pixel-square font. Being able to display text at different sizes makes a massive usability difference.
I've already written a patch that does simple arbitrary scaling of the built-in font and raised PR #6263. I've been using this in production devices for a year now, but supporting a bunch of patches is becoming a bore and I hate not being able to use the official releases so I'd like to get this PR mainlined as-is or some feedback on what I could change to get it accepted.
Thought that perhaps opening an issue might raise the visibility of this.
RFC: frame buffer module to support fast display drivers
Pyboards (PYB, WiPy, ESP8266, etc) should be able to drive displays like LCDs and OLEDs. It's currently possible to write such a driver in pure Python, and even get decent performance for small screens. But large displays (even 320x240) have a lot of pixels and doing even simple operations like filling a rectange can take a lot of time written in pure Python.
So, on the one hand, one wants display drivers written in C.
On the other hand, we want to make it easy for people to write a driver to support any display, and hence should keep writing in Python.
One idea to get the best of both worlds is to have a frame buffer module (framebuf?) which does the intensive memory copy operations, and then leave the actual interfacing to a small Python driver (eg I2C, SPI interface). This is similar in philosophy to the filesystem and the block driver protocol.
framebuf would support different colour formats (eg black and white of different bit layouts, greyscale, and RGB) so that it stores data in a way that is native to the display. It would support primitive drawing operations, region copying and font blitting.
The underlying hardware driver just needs to init the display and send the frame buffer data out on the wire.
I already implemented a proof-of-concept of this idea for the ESP8266, using an SSD1306 OLED display, and it works well.
Comments welcome! In particular, @peterhinch I'm interested if/how this could help with your epaper driver.