Epson and E-Ink developed advanced display controller

[seamusfp]

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.

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).

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.

[msundman]

Originally Posted by seamusfp

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.

But that should be done by the blitter-type thingy, not by the GP CPU/MC. The latter shouldn't have to calculate pixel data at 50 full screens per second unless you're trying to show videos in HD, and if you do then it'd be better to get a dedicated video-chip in it for that.

Originally Posted by seamusfp

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

Those are obvious features that should have been part of the first non-prototype version. If that's really what the new controller has brought to the table then it's good news, since you really need those things and I guess it's better late than never. (I got a different picture from that "seamless navigation, drop down/popup menus, responsive cursors, and real-time keyboard entry" text, but I guess I just have to learn that even technical details are sometimes written by marketing drones.)

[searcher]

"Many original equipment manufacturers thought that active-matrix electrophoretic displays were too slow for stylus input or drop-down menus—or even to keep up with a fast typist—but the bottleneck was the controller chip," said Sri Peruvemba, vice president of marketing at E Ink. "The engineers at Epson helped us design a controller chip that proves interactive applications are possible for electrophoretic displays."

With the faster Epson-manufactured controller, E Ink claims that electrophoretic displays can tackle nearly every application now served by LCDs, albeit only in black and white (or a limited number of gray scales). Applications include e-books, newspapers, -notebooks and -dictionaries; tablet PCs; and auxilliary displays for ordinary laptop computers.

Unlike a liquid-crystal display, which must refresh each pixel location about every 15 milliseconds, electrophoretic displays do not require a raster scan of the entire display. Rather, the controller only sends an electrical signal to the pixels that need to be changed. Consequently, the controller that supplies the electrical charge to the substrate can operate on a slower time scale, of about 250 milliseconds per pixel change. The new, speedier controller chip jointly developed by E Ink and Seiko Epson can change the state of up to 16 pixels simultaneously, increasing the perceived speed of the display to be on a par with that of LCDs (about 15 ms).

"We got the fastest typists we could find in our company to try it out, and none of them could type faster than the new controller," said Peruvemba. "We have also tried displaying video and have gotten a response that looks like an LCD, when in fact it is still using the same electrophoretic technology as before."

http://www.eetimes.com/news/latest/s...leID=207400055

[msundman]

Originally Posted by seamusfp

I've seen this in action

Since you seem to have some kind of inside info: do you happen to know what the frack eink devices are doing during the ~1200 ms after pressing the page-flip button and before the negative-blank-antighosting-dance starts? I just can't think of anything that wouldn't be trivial to optimize away, and that huge delay is the foremost reason why I don't own an eink device yet.

Also, does anyone know if the new controller is smart enough to do the antighosting-thingy only on pixels that are different between the pages? Or would that be impossible (maybe because the antighosting uses higher voltage that would interfere with neighboring pixels or whatever)?

[wallcraft]

What we need is a video demonstration.

How do the new hardware features map on to current API's?

[sanders]

Originally Posted by msundman

And my point was that of course those features are beneficial, but they should be implemented in software first (and that they should have been implemented in software years ago). Putting stuff in hardware is a form of optimization, and premature optimization is usually suboptimal at best and very counter-progress at worst.

I wonder why you are so acerbic regarding these controllers. Perhaps you should email Epson to let them know they're being very stupid and they should have asked you what to do first.

Perhaps the whole "partial updates" stuff has already been implemented in software. The iLiad uses an X server for its display (which I personally find strange from a technical viewpoint, since they only use full-screen apps anyway and seem to do most rendering on a pixel basis).
It is easy to have a software implementation providing sub-area screen refreshes. However, if the controller needs to update the entire screen for each of these updates to become visible, it is of very little use.

Anyway, from the new information it seems that what they mean by 16-fold parallelism is simply updating 16 pixels simultaneously, which makes the response time for the entire screen flip much higher.

[msundman]

Originally Posted by sanders

Perhaps you should email Epson to let them know they're being very stupid and they should have asked you what to do first.

Is that supposed to be funny?

Originally Posted by sanders

Perhaps the whole "partial updates" stuff has already been implemented in software.

I don't think partial updates should be implemented in software distributed to app devs. As I already wrote in #32, which you should have read before replying, I thought the new controller implemented higher level stuff such as menus. The partial update stuff should have been in the controller from the beginning.

Originally Posted by sanders

Anyway, from the new information it seems that what they mean by 16-fold parallelism is simply updating 16 pixels simultaneously, which makes the response time for the entire screen flip much higher.

I doubt it. If that really is the case then saying it will "perform up to 16 tasks in parallel" would be extremely misleading.

[sanders]

Originally Posted by msundman

Is that supposed to be funny?

No. It was a stab at "armchair experts" going off on a forum explaining how a company is doing something all wrong.

Originally Posted by msundman

I don't think partial updates should be implemented in software distributed to app devs. As I already wrote in #32, which you should have read before replying, I thought the new controller implemented higher level stuff such as menus. The partial update stuff should have been in the controller from the beginning.

In #24, you quoted my "It would be very beneficial if the controller supported arbitrary sub-area refreshes, and a few of those areas in parallel perhaps. [...] Perhaps some of the functionality is already in the current hardware." and replied "And my point was that of course those features are beneficial, but they should be implemented in software first (and that they should have been implemented in software years ago).".

Originally Posted by msundman

I doubt it. If that really is the case then saying it will "perform up to 16 tasks in parallel" would be extremely misleading.

We both know how a technical document can get mangled by marketing people before it's released. Do you remember those Intel ads where HyperThreading CPUs made it possible to read email and check for viruses "at the same time"? They're technically right, but no user would every notice the difference.

[msundman]

Originally Posted by sanders

In #24, you quoted my "It would be very beneficial if the controller supported arbitrary sub-area refreshes, and a few of those areas in parallel perhaps. [...] Perhaps some of the functionality is already in the current hardware." and replied "And my point was that of course those features are beneficial, but they should be implemented in software first (and that they should have been implemented in software years ago).".

You are right.
The only thing that would make sense of my reply in #24 would be that I didn't read carefully enough what I replied to, and that I was too caught up with thinking about higher level functions. I don't usually make mistakes like that, but it seems I made several in this thread. (I really shouldn't partake in discussions at the end of 18h workdays; if I'm mentally too tired to code then I should realize I'm also unfit for discussions.)

[sanders]

Originally Posted by msundman

You are right.
The only thing that would make sense of my reply in #24 would be that I didn't read carefully enough what I replied to, and that I was too caught up with thinking about higher level functions. I don't usually make mistakes like that, but it seems I made several in this thread. (I really shouldn't partake in discussions at the end of 18h workdays; if I'm mentally too tired to code then I should realize I'm also unfit for discussions.)

And I should probably have read #32 more carefully.

It seems we are in fact in agreement:

- Putting specific acceleration for popup menus etc. in hardware is a silly idea this early in the life cycle of e-Ink;
- We could do with partial refreshes;
- We could do with a 16-times faster refresh rate;
- It is silly to call this "16-fold parallelism" in a press release.

Cheers,
Sander

[NatCh]

Originally Posted by sanders

- It is silly to call this "16-fold parallelism" in a press release.

They have throw in something that nobody understands, otherwise Management will get the idea that the Marketing folks aren't doing their jobs right.