[mdp]

Originally Posted by Booxtor

Additionally the higher processor performance in ereaders is not really of big importance. The decision to move to new processors architecture was made in first line to offer higher Android versions compatible chip sets.

It is and is not. When you are in the act of reading - which of course is the main focus of EPD, but "reading" is not limited to the area of "traditional books" in up-to-date formats -, of course it is not important. But you want responsiveness in the general use of the interface, and it is comfortable to have pages rendering in .1 seconds instead of 1 instead of 10. But more importantly, you want responsiveness when you are using interactive applications: the foremost being "typing", text editing, and other may follow. I should mention that also hypertext consultation is a reading model that does not use the static habits of page-by-page focus; a good processor makes a difference while browsing the www. (Have you ever read the visionary milestone from Vannever Bush, 1945, "As We May Think" - introducing the Memex?)
It is because of these applications, which represent the next goal for EPD devices, that we need snappy systems.

I am a bit concerned that "new hardware (sufficient) for new software" will mean that the difference between "available capacity" and "system required load" will be constant, or not advantageous - i.e. you get similar responsiveness because the capacity grew, but also the system requirements. Instead, I wish the general responsiveness to improve. When Office Automation becomes comparable to that of the desktop (without considering the real estate constraints of mobility), I am satisfied.

Originally Posted by Booxtor

Onyx develops own techniques in order to achieve better screen performance. We have implemented the Floyd-Steinberg Dithering. I don’t know if both of the Floyd algorithm are of same efficiency.

And it is fantastic, and an excellent idea, and what I praised above.

Someone may be interested in what I wrote yesterday in a mail addressing to a different engineering team:

[...] And I need to bring your attention to the way A2 mode works on the device. A2 mode on the current Icarus Illumina XL HD works by computing a threshold of the rendered image. This makes it useless for most tasks in which it would be an asset. If you rendered a vertical gradient through your A2 mode, I suspect it will be a kind of flag, two bands, black and white. On other devices, A2 mode works as *dithering*, not as threshold. If one rendered a vertical gradient through such A2 mode, one would still see a gradient - of black dots becoming less and less diffused until complete white. Those devices allow not only - as a useful consequence - to play real animations and movies well and in a usable manner, they do a correct job in those automatic switches to A2 when scrolling through GUI elements: in your current A2 mode the text remains readable but the icons become unintelligeable; in the dithering implementation of A2 mode also the icons remain perfectly recognizable, while not fully defined.