pythoncoder wrote: ↑Mon Sep 10, 2018 6:14 pm
If you plan on a 75K frame buffer you also might need to consider the time it takes to transfer the contents to the display.
Let's explore this because I'm counting on two things:
1) Fast SPI transmission rate. The ESP32 is capable of 80MHz SPI rates though I'm not sure if we can achieve that in MicroPython today. If my back-of-the-envelope math is right at 80MHz a complete frame ought to take less than 10ms (100fps!). It's more complex of course - the ILI9341 I intend to use seems to only be rated to <7MHz but this seems to be a gross underrating as it appears it's
common to drive this much higher (20MHz is typical, 40+ possible). Even so, let's say a full frame takes 150-200ms (5-10fps); that's still usable for my purposes.
2) Partial updates. I intend to use a 'dirty row' flag in the driver so only changed rows are transmitted. The ILI9341 supports partial updates, as do many display drivers in this class. This is especially useful for
small images that require fast updates - like button icons where responsiveness is important. It's also attractive that I can implement the driver
without partial updates and build it in if/when it becomes necessary.
Does that check-out? Are any of my assumptions incorrect or misplaced?
pythoncoder wrote: ↑Mon Sep 10, 2018 6:14 pm
Most larger displays have an onboard frame buffer and built-in graphics primitives. In which case you have to choose between using it or duplicating the frame buffer on the host and zapping the whole thing across when you want to refresh the display.
I've found that when the display primitives are on the hardware you lose flexibility (eg, font selection) and you become tightly bound to the hardware. I'd like to avoid it if at all possible...
pythoncoder wrote: ↑Mon Sep 10, 2018 6:14 pm
For small displays having the framebuf on the host makes for a very simple driver by inheriting the primitives in the underlying framebuf instance, an example being
here. I find it amazing that such a trivial driver can support graphics primitives and text display in arbitrary fonts (via my CWriter class).
With the frame buffer on the host you get simplicity with high RAM use and slower speed. Using the one on the display provides performance at the cost of driver complexity. As the frame buffer gets larger, hosting it looks increasingly unappealing.
I've actually found almost the opposite - using small displays and using display driver hardware primitives means you can get good responsiveness with low-powered microcontroller hardware. As the display increases in size the limitations of the display driver hardware become more obvious and the UI looks...janky. You need more RAM and more powerful micros but the result can look better rendering into a framebuffer...
In any case, the ILI9341 I'm planning on using doesn't offer much in the way of graphics primitives.
So I'm going to
try making this work with a framebuffer!