3 ms·

Your math is correct, but the refresh rates are so low that I don’t see it being an issue. Not to mention that by the time said panel is available on the market

Your math is correct, but the refresh rates are so low that I don’t see it being an issue. Not to mention that by the time said panel is available on the market CPUs and GPUs will be better. Call it 400 dpi? 450, maybe? It doesn’t seem too farfetched to me. Also, there's a huge difference in bandwidth requirements if the display is monochrome. Consider the framebuffer needed for a conventional 8-bit colour depth display at 5000 by 7000 versus a monochrome, two colour, or a grayscale 16 shade e-ink panel. 24 bit RGB: 105 MB 5 bit grayscale: 21.875 MB 2 bit: 8.75 MB mono: 4.375 MB Pair that with a low refresh rate and partial screen updates and it's suddenly not so crazy.

chrismorgan 5y ago
Pairing it with a low refresh rate is admitting defeat. There are already multiple products on the market with full-screen refresh beyond 30Hz; Dasung’s Paperlike is probably the best known, they don’t publish an actual figure but just say it’s almost as high as LCDs; I’ve found one place of no obvious credibility saying it’s about 40Hz. All this is with ghosting, of course. High quality rendering definitely takes longer, and I get the impression from my reading and observations of a real device that bandwidth may play a part in that speed limit. Partial screen updates can go much faster than that; reMarkable 2’s total latency from marker to screen update is around 23ms if I recall correctly, and I suspect (without confirmation) that it’s updating the screen at 200Hz, the sample rate of the marker. In theory, yes, you can go down to 1- or 4-bit colour (and at 600dpi I think going hard monochrome and depending on dithering would be quite acceptable), but in practice software stacks are rather attached to 24-bit and don’t tend to like going below 8-bit. Especially general-purpose stacks—if you build something yourself from the ground up (whatever that means), then sure, you can generally choose your own path. There are certainly paths that make better use of meagre resources, but experience says they’re seldom taken. I think you’re probably underestimating how much power pushing that many pixels and that much screen bandwidth takes. Such a device is feasible (provided they can manufacture a large enough panel with a tiny enough dot pitch), but not straightforward, and will have some significant tradeoffs. I’m not surprised no one’s trying anything even close to it.
- jagger27 5y ago
  > All this is with ghosting, of course. High quality rendering definitely takes longer, and I get the impression from my reading and observations of a real device that bandwidth may play a part in that speed limit. You’re talking about a general purpose monitor attached to a PC. How is bandwidth an issue there? The very same computer can push 120 Hz (or more) to higher res screens than the Dasung. It seems very clear to me that the problem is that the e-ink cells physically can’t react in time to show the next frame. The ghosting means they’re pushing it to the limit. If you’re talking about the controller within the display, well that argument doesn’t track. Controllers capable of pushing pixels that quickly work perfectly fine in conventional LCDs, even power constrained ones like an iPad Pro’s. Why not use those? E-readers have been monochrome for over 20 years, not to mention every other limited-colour piece of hardware. Has that not been enough time for software to adapt and libraries to mature? To be clear, I’m not dreaming of a device to run X11, Firefox, and Doom (like the PineNote people seem to want). I want self-rewriting paper. Of course I want software tailored to that experience, not something off the shelf. If I am making any ridiculous requests, it’s 600 dpi screens at that size. I’m sure there are a thousand reasons why that’s a hard engineering problem.

chrismorgan 5y ago

Pairing it with a low refresh rate is admitting defeat. There are already multiple products on the market with full-screen refresh beyond 30Hz; Dasung’s Paperlike is probably the best known, they don’t publish an actual figure but just say it’s almost as high as LCDs; I’ve found one place of no obvious credibility saying it’s about 40Hz. All this is with ghosting, of course. High quality rendering definitely takes longer, and I get the impression from my reading and observations of a real device that bandwidth may play a part in that speed limit. Partial screen updates can go much faster than that; reMarkable 2’s total latency from marker to screen update is around 23ms if I recall correctly, and I suspect (without confirmation) that it’s updating the screen at 200Hz, the sample rate of the marker. In theory, yes, you can go down to 1- or 4-bit colour (and at 600dpi I think going hard monochrome and depending on dithering would be quite acceptable), but in practice software stacks are rather attached to 24-bit and don’t tend to like going below 8-bit. Especially general-purpose stacks—if you build something yourself from the ground up (whatever that means), then sure, you can generally choose your own path. There are certainly paths that make better use of meagre resources, but experience says they’re seldom taken. I think you’re probably underestimating how much power pushing that many pixels and that much screen bandwidth takes. Such a device is feasible (provided they can manufacture a large enough panel with a tiny enough dot pitch), but not straightforward, and will have some significant tradeoffs. I’m not surprised no one’s trying anything even close to it.

jagger27 5y ago
> All this is with ghosting, of course. High quality rendering definitely takes longer, and I get the impression from my reading and observations of a real device that bandwidth may play a part in that speed limit. You’re talking about a general purpose monitor attached to a PC. How is bandwidth an issue there? The very same computer can push 120 Hz (or more) to higher res screens than the Dasung. It seems very clear to me that the problem is that the e-ink cells physically can’t react in time to show the next frame. The ghosting means they’re pushing it to the limit. If you’re talking about the controller within the display, well that argument doesn’t track. Controllers capable of pushing pixels that quickly work perfectly fine in conventional LCDs, even power constrained ones like an iPad Pro’s. Why not use those? E-readers have been monochrome for over 20 years, not to mention every other limited-colour piece of hardware. Has that not been enough time for software to adapt and libraries to mature? To be clear, I’m not dreaming of a device to run X11, Firefox, and Doom (like the PineNote people seem to want). I want self-rewriting paper. Of course I want software tailored to that experience, not something off the shelf. If I am making any ridiculous requests, it’s 600 dpi screens at that size. I’m sure there are a thousand reasons why that’s a hard engineering problem.