Hacker News Clone new | comments | show | ask | jobs | submit | github repologin
Text editor design for e-ink displays (canonical.org)
5 points by rbanffy 2 hours ago | hide | past | web | 1 comment | favorite





I have been working with various e-ink displays and most of them offer these capabilities:

(1bpp black and white or 4bpp 16 shade scale from black to white displays are what I am writing about here. Color displays and or very basic displays probably do not have these same options)

Partial screen or zone

This is generally a rectangular zone that gets refreshed.

Whether one refreshes a zone or full screen, it takes a while to go through the usual black to white to text flashing we have all come to know well.

And this is roughly 2 seconds, with zones being a bit faster, but not by too much.

Complete refresh

This is the full flashing black to white to image cycle. Slow.

Partial Refresh

This one simply redraws changed pixels only and does not feature the flashing effects. The pixels are just changed.

Partial refresh time

Here we specify the pixel change time allowed. And it can be fast!

The faster we go, the more left over screen artifacts or "ghosting" remains on the display. In addition, all the e-paper displays I have tried say you need to perform a complete refresh every so often to avoid the display reaching some partially charged state, which can leave it unusable.

My experience is most displays can go a long time using fast partial refreshes with no damage. If one does appear damaged, with damage looking like persistent patterns of partially visible or even completely visible pixels, running the display overnight using full refresh on a simple full screen task will generally restore the display to factory performance.

I have abused mine a lot and have been able to recover each time by doing that. Just have it display a count, or any simple changing image each cycle and watch it improve.

Partial refresh times range from about 50ms on the extreme fast end of things, through 100 to 150ms for still fast but reasonably clean display images, ending at about 250ms for very good images.

All with no dark to light to image flashing!

The 50ms through 80ms times result in light grey, partially drawn pixels and lots of leftovers. I have found those left overs can be largely hidden by drawing the whole display with a black rectangle, which leaves it all light gray. Then draw your fast images from there and the leftovers are basically the same grey. Not perfect but more usable than you may expect!

For text, one could target 6 to 10 frames per second and get a very readable display with few moderate artifacts. The entire display is redrawn each frame.

Plenty fast for editing text.

If it were me, I would draw the text in high quality, high contrast 250ms draw time rate and that is 4fps for paging through, just reading, searching, etc...

Then, the moment editing is about to happen, simply redraw the region near cursor faster to allow for editing to happen above 10fps.

Anytime the user pauses for a full second, or some close enough time, draw it all high quality again.

Or maybe even just give the user two modes. Fast and slow.

Let them choose.

Given what I have seen, I would use slow for using text to read, and fast mode for edits and just let the screen contrast be reduced and artifacts be seen.

Any pause and those will just go away.

Put the full refresh on a long timer, say 5 to 10 minutes to make the display charge state stay happy.

Also put a high quality redraw on a hot key for the user to trigger anytime they want a cleaner display.

Done this way, a user never has to endure the black to white flashing update nobody likes, until it makes sense. And they get a fast display that looks as good as they need it to much like the AUTOCAD refresh/redraw comments here talk about.

I have a game tech demo running on one of these black and white, no grey scale, displays using these capabilities, and it is fast!

I will see if I can link some video, but I have a few hundred small moving objects and a player ship one can fly around. It runs at 13fps and is totally playable should it become a full shoot the other things Asteroids type game.

And that's just python with the display running over 20mhz SPI.

I think the author has great observations, and would be very curious for their thoughts given some knowledge of the many display options available to them.

Feels to me like they saw a Kindle and were approaching the topic assuming Kindle level draw capability, which is far less than what most e-paper can really do.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: