> I wonder if the issue would be more how to get such an optimization to the display
This
> Although perhaps it automatically does a comparison between current and previous frame to do its own dirty-pixel optimization.
Some do, like the Boox regal mode, but it stills feels a bit slow and leaves some ghosting. Baking that into the terminal would limit the comparison to the invalidated area, which in a terminal would be a smaller square that the full screen frame, so I'd expect some speed gains.
I wonder if maintaining a buffer in software that counts for each pixel how many times it has been dirty, combined with, say, the kind of quadtree one would normally use for hit detection, would let one do "local" refreshes and make this a generic solution. It sounds like the kind of thing that someone already must have thought of (let's hope it's not one of the software patents holding e-ink back)
This
> Although perhaps it automatically does a comparison between current and previous frame to do its own dirty-pixel optimization.
Some do, like the Boox regal mode, but it stills feels a bit slow and leaves some ghosting. Baking that into the terminal would limit the comparison to the invalidated area, which in a terminal would be a smaller square that the full screen frame, so I'd expect some speed gains.