Quote:
Originally Posted by msundman
You're writing some kind of pixel data for all pixels on the screen at 50 fps on an eink display? Seems unlikely.
Also, what you described takes neither memory (1-4 bytes/pixel seems enough) nor time (small LUTs seems enough).
|
I can see how you would doubt 50Hz, but it's true. That is the time quanta available for the flashing that occurs during an update. The LUT's can get quite large since they store what voltages are being applied in 20ms slices for up to a second.
Quote:
Originally Posted by msundman
Yes, of course you need some kind of frame buffer or blitter or whatever. My point was that this custom chip should be as generic as possible instead of implementing specific high level concepts such as menus or whatever. At least until it's been shown exactly which things are too slow (or takes too much power) to do in software without specific hardware-acceleration.
|
From what I understand this is a rather generic platform, providing things like the ability to address small sections at faster rates for things like inset animations, subdivide the screen and address the divisions differently, enabling things like fast response pen input (better than the Iliad), responsive text entry (I've heard >100PWM).
Quote:
Originally Posted by msundman
OTOH, the optimizations might turn out to be very good, and in that fortunate case => happy happy joy joy  |
That's what I wanted to see.
As I said before, I've seen this in action and it's impressive. I was not trying to flame you merely convey that there are sound reasons for this to be hardware, as well as plenty of development behind it. If I'm not mistaken this is at least the 4th generation of E Ink controllers.