Technical Question about e-ink

Can anyone tell me why e-ink displays need to 'flash' between pages?

It's as though it has to clear the screen then redraw it in front of you.

Occasionally in videos on YouTube I see what can only be described as a double update (ie a definite page change then a redraw of the same page).

It's as though the frame buffer for the screen is the screen itself rather than another area of memory.

Students learn that flickering in computer animation occurs because you momentarily see a blank screen before the next frame is redrawn. A technique known as double buffering alleviates this by doing the clearing and redrawing 'off screen' then block transferring the new frame in a single pass

Is there something inherent in the design which prevents this for e-ink?

Is there some way to do a 'delta' update of the screen? i.e. Most of the page in an e-book will remain white between pages. Surely it would be more battery friendly (I understand that, like CMOS, e-ink only draws power during a change) and easier on the eye to only change the pixels which differ between the pages......

I've seen basic animation performed on an e-ink screen showing that some kind of delta updating mechanism should be possible: http://www.youtube.com/watch?v=3n2xxqMQyfY

or even the October 2008 Issue of Esquire magazine which contained an e-ink section on the front cover has a non flickering (actually more of a fading effect) animation
http://www.youtube.com/watch?v=9EWb1zHIx38

The impression I get (again from YouTube) is that the Edge page change is slightly quicker than say a Kindle DX (is this true?) but I'm sure there must be a way to prevent the annoying black page screen update when changing pages.

BTW I managed to win a White Entourage Edge on Ebay ! So I'm looking forward to perhaps having secured one of the quickest delivered and cheapest Edges in the UK ! I'm am so lloking forward to getting it especially with the recent software update that everyone is raving about !

In short I love the camaraderie which shines throughout this forum, which will make the Edge the success it deserves to be.


P.S. You can be as technical as you like in the replies - I have a science based Ph.D. so no need to be gentle with me

Hmmm I've just had a thought....surely the Wacom pen input is a prime example of delta updates to the e-ink reader.

drsteve, it's all depends on e-ink driver. eDGe use their own driver and seems it's not good optimised.

Kindle DX is far faster then any other e-ink reader I saw and also support 16 levels of gray. EE is noticeably slower and has only 8levels of gray. But hope it'll be improoved in the future.

@Boris
Thanks, Boris. I had already seen that blog and understand that what this might be is just a refresh time artifact. However surely some sort of delta update mechanism or double buffering technique would reduce the definite two stage clear/redraw that one sees. You're either not changing so many pixels or you're only doing one screen refresh instead of the whole screen twice. I was just wondering whether this is something which can be improved in software/firmware or whether it was an artefact one has to live with.

@robot
zdravstvuitye Tovarish - I've read your other posts. Have you actually dismantled/rooted the Edge?. I remember you saying that the 16 levels of grey is potentially unlockable. Do you think that future software updates might improve things? I'm sure once the SDK goes public we'll see some great things.

Originally Posted by drsteve

Hmmm I've just had a thought....surely the Wacom pen input is a prime example of delta updates to the e-ink reader.

Write with a different "color" other than black and you'll notice a flash in the pixels following the pen. The screen update done for non-black pixels appears to force the titanium oxide particles to the maximum negative or positive charge before transitioning to the intermediate charge for the corresponding shade of grey.

Originally Posted by borisb

Your original post was asking about "flash" between pages, and went on to guess about a wipe/redraw vs delta updates. I thought the blog post explained that the flash is because of the eInk needing to be reset before being redrawn...? Of course, a full screen wipe & redraw is easy to code, but as robot indicates, if a delta refresh could be calculated and performed, the performance may be smoother and faster.

We do a full page refresh in between page changes to minimize the ghosting effect. A partial update (which is used in the Journal when writing on the screen) is quick, but is can only do white-->black and black--> white, and has a tendency to leave a "ghost" image.

I guess at the end of the day, we're dealing with a capacitor with an oil dielectric. It would appear that any change in voltage leads to some kind of negative spike which pulls the TiO2 quickly down to the lower electrode (leaving the black oil - very X-Files !) followed by a relatively slow relaxation to the newly applied voltage where the TiO2 drifts back to the surface electrode. Hence my assertion that only changing the pixels which require changing might potentially alleviate the effect. I imagine white to black would be quite fast whereas black to white would be slightly slower. But at least that would be a fade rather than a 'flash'. P.S. Apologies for the geek attack displayed in this reply

Ah, during the writing of my last post it seems PonMan has given the reason ! Would driving the e-ink display the other way help? ie producing a white flash rather than a black one?

lol. Tovarish
No, not rooted yet:
1. 'cos it's a little risky.
2. root by itself doesn't give new features. At this time I'll probably able only to add custom fonts, replace bootanimation and so on. Nothing really interesting.
3. So I need some help from geek with advanced knowledge of linux\android.

Currently I'm looking at the browser app code to understand how interaktion with e-ink works. There about 70 files so it will takes time.

Displays generated by a continuous scanning process benefit from double buffering. The display buffer can be swapped between drawn fields, so a partial field is not shown, so no update flicker is visible.

The eInk display is not like this at all. After the display is updated, the image is static. So, double buffering would not provide any benefit. My iRex Iliad (and every other eInk device I've seen) updates the screen between pages in a similar way as the edge.

I'll guess that the programmers determined that the average delta between typical book pages is significant enough to make delta eInk display updates slower than just wiping the page to a neutral state and putting up the next page. Second guess: Partial updates are tricky and likely to leave a mess behind.

The animation shown on the cambridge eInk device is extremely small. The edge can probably manage that with some programming. (Oh, where or where is the SDK? Oh, where or where can it be? )

The eInk display on the cover of Esquire behaves more like a glorified monochrome LCD. It appears to have only fixed pattern segments in white and black (ok, dark grey). (If someone hacked it to show something different, I'd like to see it.) So, based on the behavior I'll guess the thing can only switch between minimum/maximum charges in the eInk pixels. Probably not the best example for comparison to the larger, general purpose screen on the edge.

@kenjennings I think you're spot on about the fixed pattern segments on the Esquire cover. Sheer cost alone precludes the screen being little more than a glorified electrically controlled two state hologram. PonMan has confirmed that the EE does a deliberate clear between each page change. What I'm wondering now is can they drive the display in such a way that the clearing process produces an intermediate white page rather than an intermediate black page. This I imagine may still lead to some sort of ghosting for which the black flash is the only solution. So I guess it looks like we're stuck with the flashing.

Originally Posted by robot

Currently I'm looking at the browser app code to understand how interaktion with e-ink works. There about 70 files so it will takes time.

I'm not sure you'll find any direct interaction with the e-ink side. I imagine the code merely produces a pdf/epub version of the LCD screen, produces an intermediate file on disk then uses the firmware/OS to display that file on the e-ink side. It's a bit like the difference between talking to a browser ActiveX control using the DOM vs pointing the control at a file:// URL

Originally Posted by drsteve

I'm not sure you'll find any direct interaction with the e-ink side. I imagine the code merely produces a pdf/epub version of the LCD screen, produces an intermediate file on disk then uses the firmware/OS to display that file on the e-ink side. It's a bit like the difference between talking to a browser ActiveX control using the DOM vs pointing the control at a file:// URL

Yes, but there's something interesting. In order to make PDF eDGe make several screenshots of the page in PNG format, then send them in PDF converter... it's kinda slow, and not so smart on the one side, but on the other side if I'll find to directly capture LCD display content and send it to e-ink... or to send request from e-ink side to browser....
Need help from developers to understand how it can be done