4 ms·

Wouldn't the very slow refresh rate of eInk be an issue here?

by Bud 11y ago

paulmd 11y ago
I actually found a video of a Kindle being used as a terminal: https://www.youtube.com/watch?v=ymei7UwBgX4 https://www.youtube.com/watch?v=ymei7UwBgX4 Looks like it's running a pretend-terminal website which probably explains the latency (the Kindle does not have a fast processor). Way on the other end - here's a Dasung 13.3" eInk monitor (i.e. you feed it DVI and it handles all the display driving for you). It can be yours for a cool $1000. I'll pass, but it's looking pretty good even for GUI usage. Probably uses more power than a purely embedded solution could, though. https://www.youtube.com/watch?v=vny-JTpt-aU https://www.youtube.com/watch?v=vny-JTpt-aU
- groovy2shoes 11y ago
  I want one of those monitors so bad. Why does it have to be $1000?! Anyone willing to contribute to my Indiegogo campaign? ;)
  - kqr 11y ago
    I want one too. Suddenly, I know what I'd do if I won the lottery.
- i336_ 11y ago
  FYI, I've seen virtually zero latency running livereload experiments with the embedded browser in my Kindle, the basic 3rd-gen 2014 model. My method was extremely rudimentary - inotify -> long-polling JS (being fed entire new file) -> innerHTML rewriting, with the Kindle connected over 802.11g - but hitting Save in my editor produced updates on the Kindle's display in around around 20-40ms. I would put a moderate amount of money on the possibility that the latency is coming from the fact that the terminal app in the video is being run on a non-local server, and that keystrokes have to go up to the cloud-hosted app and then come back down to get onto the Kindle's display. If the whole thing were local (with the terminal app hosted on target system, ideally) I expect updates could happen in <100ms. Also, the CPU is a 1GHz i.MX6 (@ 996MHz), next to 400MHz LPDDR2 (@ 396MHz). It performs quite well in my experience; it's the OS that's terrible. :P (The best OS I've yet seen was the one on my Ericsson MC218, which let me drag windows around the display faster than the LCD crystals could physically keep up. Solid windows, not outlines. On an ARM7TDMI running at 36MHz.)
akamaka 11y ago
No idea about the refresh rate of eInk displays, but terminals were always designed to work over slow connections. So long as your configuration is pretty traditional (e.g. your text editor scrolling half a page at a time instead of line by line), it should be quite usable by 1970s standards.
JoshTriplett 11y ago
Many bi-stable displays can be quickly set in one direction, and only have a slow refresh cycle for clearing or "cleaning" the display. Given that, a terminal based on e-ink could potentially display characters quickly and only be slow when clearing or scrolling. That'd still be painful for interactive use, though.
clevernickname 11y ago
I suspect it would. I ended up giving away my Kindle partly because the delay in page turning[1] was long enough to bother me. I can't imagine typing with such a display. An article on here a little while back goes into detail about how even very small latencies affect the typing process: https://news.ycombinator.com/item?id=10787812 https://news.ycombinator.com/item?id=10787812 [1] Yes, I know it takes longer on an e-ink display to refresh the entire screen than to update a single character. My point is that page turning speed is thought by most to be unimportant, but being used to PC interfaces with fast response times made it unbearable to me, especially when I was skipping through pages trying to find something.
outworlder 11y ago
Would that be significantly slower that phosphor persistence of old displays? Actually, depending on what you are doing, the nostalgia-induced slowness might even be intended.

Wouldn't the very slow refresh rate of eInk be an issue here?

by Bud 11y ago

Wouldn't the very slow refresh rate of eInk be an issue here?

I actually found a video of a Kindle being used as a terminal: https://www.youtube.com/watch?v=ymei7UwBgX4 https://www.youtube.com/watch?v=ymei7UwBgX4 Looks like it's running a pretend-terminal website which probably explains the latency (the Kindle does not have a fast processor). Way on the other end - here's a Dasung 13.3" eInk monitor (i.e. you feed it DVI and it handles all the display driving for you). It can be yours for a cool $1000. I'll pass, but it's looking pretty good even for GUI usage. Probably uses more power than a purely embedded solution could, though. https://www.youtube.com/watch?v=vny-JTpt-aU https://www.youtube.com/watch?v=vny-JTpt-aU

groovy2shoes 11y ago
I want one of those monitors so bad. Why does it have to be $1000?! Anyone willing to contribute to my Indiegogo campaign? ;)
- kqr 11y ago
  I want one too. Suddenly, I know what I'd do if I won the lottery.
i336_ 11y ago
FYI, I've seen virtually zero latency running livereload experiments with the embedded browser in my Kindle, the basic 3rd-gen 2014 model. My method was extremely rudimentary - inotify -> long-polling JS (being fed entire new file) -> innerHTML rewriting, with the Kindle connected over 802.11g - but hitting Save in my editor produced updates on the Kindle's display in around around 20-40ms. I would put a moderate amount of money on the possibility that the latency is coming from the fact that the terminal app in the video is being run on a non-local server, and that keystrokes have to go up to the cloud-hosted app and then come back down to get onto the Kindle's display. If the whole thing were local (with the terminal app hosted on target system, ideally) I expect updates could happen in <100ms. Also, the CPU is a 1GHz i.MX6 (@ 996MHz), next to 400MHz LPDDR2 (@ 396MHz). It performs quite well in my experience; it's the OS that's terrible. :P (The best OS I've yet seen was the one on my Ericsson MC218, which let me drag windows around the display faster than the LCD crystals could physically keep up. Solid windows, not outlines. On an ARM7TDMI running at 36MHz.)

akamaka 11y ago

No idea about the refresh rate of eInk displays, but terminals were always designed to work over slow connections. So long as your configuration is pretty traditional (e.g. your text editor scrolling half a page at a time instead of line by line), it should be quite usable by 1970s standards.

JoshTriplett 11y ago

Many bi-stable displays can be quickly set in one direction, and only have a slow refresh cycle for clearing or "cleaning" the display. Given that, a terminal based on e-ink could potentially display characters quickly and only be slow when clearing or scrolling. That'd still be painful for interactive use, though.

clevernickname 11y ago

I suspect it would. I ended up giving away my Kindle partly because the delay in page turning[1] was long enough to bother me. I can't imagine typing with such a display. An article on here a little while back goes into detail about how even very small latencies affect the typing process: https://news.ycombinator.com/item?id=10787812 https://news.ycombinator.com/item?id=10787812 [1] Yes, I know it takes longer on an e-ink display to refresh the entire screen than to update a single character. My point is that page turning speed is thought by most to be unimportant, but being used to PC interfaces with fast response times made it unbearable to me, especially when I was skipping through pages trying to find something.

outworlder 11y ago

Would that be significantly slower that phosphor persistence of old displays? Actually, depending on what you are doing, the nostalgia-induced slowness might even be intended.