4 ms·
One of these days, I want to make a terminal "optimized" for eink - as in, compute which parts of the screen receive the new characters, to invalidate them and
by csdvrx 4y ago
One of these days, I want to make a terminal "optimized" for eink - as in, compute which parts of the screen receive the new characters, to invalidate them and do a quick refresh (leaving eink ghosting) on these leaving the rest of the screen pristine, then later do at an opportunistic time a better refresh (leaving no ghosting) on these to have no ghosting at all instead of leaving the selection of that time to the eink driver.
Eink refresh is slow-ish, but only because if say scrolling a bunch of pixels, you need to invalidate and redraw the whole screen.
The advantage of terminals is that you can easily keep a matrix of squares, and by looking at the flux of information, you can pick the opportunistic times for refreshes.
With characters, there should be more recouping. (a B and a P overlap except in the bottom right)
With line editing, the problem should be limited to the line
All these small gains should add up to provide an excellent terminal experience.
- vanderZwan 4y agoI am fairly certain that I have read that these types of optimizations (only change dirty characters) already exist in certain terminals. I wonder if the issue would be more how to get such an optimization to the display. Although perhaps it automatically does a comparison between current and previous frame to do its own dirty-pixel optimization.
- csdvrx 4y ago> 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.
- vanderZwan 4y agoThank you, I understand your intent better now. 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)
- braunboffel 4y ago> let's hope it's not one of the software patents holding e-ink back Which patents are these?
- hedora 4y agoYou're describing the initial motivation for the vi user interface. (It targeted ~300 baud terminals.)
- csdvrx 4y agoMuch to my regret, I've never experienced 300 baud terminals (too young for this) I've just heard about how great their hardware was. I'm a huge admirer of terminals and especially obscure stuff like sixel and regis. Right now, we seem to be in a vi revival period, and we've new hardware (eink) that bring back old problems (latency + screen update speed) vi was made to tackle, along with new ones (2 refresh modes, one of which can leave ghosting) that should be easy to fix. So I can't help but notice how vim on eink just needs this one little extra thing to give a great experience on modern hardware