4 ms·

There are eInk specific things that a graphics controller needs to know about, like flashing the screen (or a region) after an update to eliminate ghosting. So

There are eInk specific things that a graphics controller needs to know about, like flashing the screen (or a region) after an update to eliminate ghosting. So it would probably make more sense for the communication between the host and the panel to be at a higher level than a bitmap of the entire screen - something more like the Windows GDI, Display Postscript or Xlib. Sure, you'd occasionally need to blit in the whole screen, but you could limit the number of pixels to update, and limit the number of updates per second. I'd much rather have a display that doesn't suck up all my USB bandwidth. If you are going to do that, you might as well use the Thunderbolt port. But then you just have a big, expensive grayscale screen with a low refresh rate.

beagle3 14y ago
That's nice in theory, and would have worked in 1995, perhaps even as late as 2003. But nowadays, almost every toolkit on almost every platform does rendering to an off-screen bitmap, and then copies (or "composes") that bitmap onto the screen - so even if only one pixel is changed, that's often lost in the pipeline. However, something like VNC's and RDP's "tile" coding (that is, remembering for every non-overlapping n by n rectangle whether its content has changed since last update) would still work.