Unfortunately the fast color displays (we can buy) are not there yet. Only black & white (and grayscale) ones are fast enough to be used as somewhat generic screen you can interact with
I just did a project with one. You are right, the three (or more) colour screens do indeed have very slow update cycles, and they usually don't support partial refresh either (just updating part of the screen)
BUT there are some tricks you can do. You can start most of them in two-colour mode, which does support partial updates, and you can define and upload a custom set of waveforms that govern how the screen performs its refresh and update cycles. I wrote an email to the company I purchased from (good-display) and they were very responsive and sent me some waveforms to try. These allow a much faster update (~1s) at the cost of some slight greyness, which gets worse over time, needing a full refresh after a while.
The resulting code I wrote now does something like -
- start device (colour)
- draw background in colour (15 seconds)
- every minute, restart device (B/W) and draw 'active' areas (1 second)
- every 15 minutes redraw background (full screen update, 15s)
- every 24 hours run a screen refresh routine(1 minute plus)
(my screen refresh routine cycles each pixel through each of the colour transitions, black->white, black->red, white->red, and the reverse)
Effectively I had to piece together some clues. There was the manual for the screen which gave the definition of the SPI protocol in use, and the commands you could send, what they did, screen startup sequence etc. They mentioned waveforms and modes a bit but it was frustratingly incomplete and it looked like there were gaps in the commands described. Then there was a youtube video of a guy showing how he'd implemented fast refresh on some other model of screen by uploading custom waveforms, who mentioned looking for waveforms in sample code and for chip specifications. This lead me to the original docs for the driver chip on my display (an ultrachip UC8179) which had the missing commands specified. Using these along with the waveform (LUT) definitions supplied by the vendor when I asked them for some, allowed me to make the fast mode.
I presume some commands were missed out of the vendor document as a lot of them were non-essential, and possibly could cause harm(?). Certainly the wrong waveforms could lead to poor performance or no performance. Also the chip spec document didn't give some of the higher level "Here is the startup sequence for your screen" flow chart niceties of the vendor doc.
(The waveforms are literally describing how the screen should apply voltages to transition a pixel from one colour to another. The default ones that the screen ships with are good for a 'full' refresh of the pixel, but you can get away with a lot fewer, faster voltage switches for B/W, at the cost of quality declining over time, which you reset with a periodic 'full' refresh)
The full-color (7 or 8 colors to mix) take forever to update, but if you’re just displaying a photograph, update it at 2am and no one knows the difference.