_8rlb

I found this rule in notes of Feynman's lecture given in the 70's. The rule is extremely valuable if you are in need of doing calculus regularly. Enjoy!

Yes! But intuition tells me that suspended particles moving past each other make a more fragile system than solid state devices.

Also take into account the difference in refreshes between reading a book (0.05 HZ) and writing (30 HZ). That is, using the display as a general purpose monitor necessitates 600 times as many partial refreshes. I approximate full screen refreshes occur 6000 times more often.

If degradation goes linearly with usage then the lifespan of the display would decrease significantly if used as a monitor. It would be good if someone in the industry could comment on this.

Yes, with his permission.

It is on ubuntu, for sure.

There is a lot of room to play with there, I code monochrome on colour displays too.

Try experimenting with font weight, italics, and combinations. I find that less distracting.

The degradation is speculation on my part. I haven't ever experienced it.

Yes, the 30 fps rate is for small updates. A full screen update (scrolling) is commonly less than ~200 ms, and there are still ways to bring that number down.

I agree, the Libra 2 is great :) Try koreader, it's noticeably faster than the stock reader application.

P.S. parent was right in doubting the claim, as a parallel connection from a client on a regular desktop refreshes at 30 HZ regardless of the size of the update.

The explanation is that I take end-to-end network measurements (from request of update to a full buffer of pixel bytes). That delay might be due to the slow processor on device, or an inefficiency in the networking code in my application.

The pixels are classical mechanical, as opposed to LEDs (electrical) or other solid state devices.

The particles in a pixel could deform/burst or clamp together over time, as they move around. Both scenarios lead to decreased contrast.

The less they move the longer the screen will last. I've no experience with the manufacture of those displays but I reason with physics.

I measured and split the latency between the main tasks of a single frame draw.

The main culprit was network delay as I am transmitting raw pixels (one u8 per pixel) compressed with zlib. That's a hit of ~140ms for half a screen.

Next in line is the screen refresh (unmeasured, perceived).

Then the optional post processing (~20ms for half a screen), and housekeeping, like keeping track of dirty regions (about as long).

Lastly writing to the framebuffer (less than 20ms, I don't remember exactly how long).

I took great care to optimise the process, and my next step was to transmit multiple pixels as a single u8 int, the physical display cannot render 255 distinct shades of gray.