4 ms·

I was watching a bunch of YouTube reviews of some of the current generation of ereaders. And what struck me the most is how good the refresh rate was on some of

by cskau 14y ago

I was watching a bunch of YouTube reviews of some of the current generation of ereaders. And what struck me the most is how good the refresh rate was on some of these devices. In the some of videos they show how even pinch zooming and panning around is possible, which I think is really impressive. Surely it's not the rate of an LCD but I bet it would be near usable for coding. I guess what I would miss the most is color syntax highlighting. I'm curious, since you mention USB, if you've done any calculations on USB vs Eink bandwidth? Would USB2.0 have enough to keep up with 24" worth of "pixels" even at Eink's relative low refresh rate? Or would USB3.0?

shrughes 14y ago
Let's say it's 24" at twice the resolution of 1920x1200 or four times the pixels, with 8 bit grayscale (because this is a fancy e-ink display, after all). USB 3.0 can do 5 Gbps which means 67 Hz would be an upper bound.
- mistercow 14y ago
  >USB 3.0 can do 5 Gbps which means 67 Hz would be an upper bound. That's assuming that it's uncompressed, and if you're talking about using it largely for text, not compressing would just be crazy. For that kind of input, you can easily get 10x compression ratios losslessly. And at that resolution you can get away with extremely aggressive lossy compression, and ratios on the order of 50x are totally plausible. There's no reason for bandwidth to be a problem here.
  - m_eiman 14y ago
    Lossy compressions would probably be very annoying, imagine having slow-motion MPEG defects around everything that's updated :P
    - mistercow 14y ago
      No need to use interframe compression. Just JPEG will get you around 50x ratios with virtually no discernible artifacts at pixel densities that high (for mostly-text input). And there's no slow-motion about it; the whole point of compressing is to allow for very high framerates. If you can't get the E Ink to push 30hz, then there's probably not much reason to use lossy compression anyway. If you can get over 30hz, then lossy compression will keep you from totally saturating the USB 3 bus.
- jamesmcn 14y ago
  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.

by cskau 14y ago

shrughes 14y ago

Let's say it's 24" at twice the resolution of 1920x1200 or four times the pixels, with 8 bit grayscale (because this is a fancy e-ink display, after all). USB 3.0 can do 5 Gbps which means 67 Hz would be an upper bound.

mistercow 14y ago
>USB 3.0 can do 5 Gbps which means 67 Hz would be an upper bound. That's assuming that it's uncompressed, and if you're talking about using it largely for text, not compressing would just be crazy. For that kind of input, you can easily get 10x compression ratios losslessly. And at that resolution you can get away with extremely aggressive lossy compression, and ratios on the order of 50x are totally plausible. There's no reason for bandwidth to be a problem here.
- m_eiman 14y ago
  Lossy compressions would probably be very annoying, imagine having slow-motion MPEG defects around everything that's updated :P
  - mistercow 14y ago
    No need to use interframe compression. Just JPEG will get you around 50x ratios with virtually no discernible artifacts at pixel densities that high (for mostly-text input). And there's no slow-motion about it; the whole point of compressing is to allow for very high framerates. If you can't get the E Ink to push 30hz, then there's probably not much reason to use lossy compression anyway. If you can get over 30hz, then lossy compression will keep you from totally saturating the USB 3 bus.
jamesmcn 14y ago
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.