View Single Post
Old 02-03-2010, 11:18 AM   #5
badbob001
Fanatic
badbob001 ought to be getting tired of karma fortunes by now.badbob001 ought to be getting tired of karma fortunes by now.badbob001 ought to be getting tired of karma fortunes by now.badbob001 ought to be getting tired of karma fortunes by now.badbob001 ought to be getting tired of karma fortunes by now.badbob001 ought to be getting tired of karma fortunes by now.badbob001 ought to be getting tired of karma fortunes by now.badbob001 ought to be getting tired of karma fortunes by now.badbob001 ought to be getting tired of karma fortunes by now.badbob001 ought to be getting tired of karma fortunes by now.badbob001 ought to be getting tired of karma fortunes by now.
 
badbob001's Avatar
 
Posts: 556
Karma: 1102020
Join Date: Sep 2009
Device: Kindle Keyboard (rip), Kindle Voyage, Fire Tablet 10 '17, iPad '19
That demo did look very interesting, though it's hard to say if it's faster than current implementations. It shows the demo rapidly updating the screen, though we have no idea what the delay is from when the program draws on the screen and when the screen actually updates. I'm guessing if the dev unit supported sytlus/finger touch, we can see how quickly the unit can keep up.

It is also impossible to tell if such fast updates leaves after-images (ghosting) on the screen, which may not show up in a demo but will when viewing many pages of text. Current controllers probably try to find a compromise between speed and anti-ghosting techniques. Some controllers, in response to a page turn, like to just refresh just the parts of the screen with text while other controllers (irex's delta) wants to refresh the entire page. There is probably different battery cost to each method (perhaps Irex's usage of the faster and cleaner entire refresh method is why their devices are less battery efficient).

But I do agree than the current CPUs on readers is too slow since much of the screen refresh time is not due to the e-ink.
badbob001 is offline   Reply With Quote