Quote:
Originally Posted by msundman
That's pure hogwash. Eink is so incredibly slow at the moment that I'm sure even slow microcontrollers could handle it with only small amounts of custom h/w. (Well, at least the smaller displays, not necessarily a 2048*1536 one.)
Unless it's several tens of bytes per pixel (and I'd be surprised if it was) then I don't see a problem.
|
You'd be surprised... prior state information, temperature compensation, waveform, etc. If the device is already going to be sluggish because of the displays rate, I'd rather not have it additionally bogged down keeping track of 0.5 million pixels and clocking out (~800x600) every 20ms.
Not to mention most embedded processors have an LCD controller of some sort, so it's not like this is an unheard of even for simplier display technologies
http://www.intel.com/design/embedded...ors/302302.htm look at that, an LCD controller built right on the die of the processor. This sort of controller is largely abstracted from the developer as just putting data into the frame buffer.
Quote:
Originally Posted by msundman
Really? So eink has given s/w libs to app devs to use when implementing their apps, and then eink has listened to their responses? Or has eink just done internal testing and tried to figure out what app devs might wish for? The latter approach has time and again failed miserably.
|
This device went through an extensive beta program with many device manufactures, and yes, feedback.
Quote:
Originally Posted by msundman
I'm sorry, but that's maybe the most clueless statement I've ever seen, and is right up there with Gate's "640k should be enough for everybody". The least you could do is add an "[...]using any currently available, GP CPUs/microcontrollers." or somesuch.
|
Fair enough, but since we are talking devices which would be released in the near future, the current hardware was implied.
Quote:
Originally Posted by msundman
Still, that's beside the point. I've myself designed libs that did amazing things, yet it turned out that the devs wanted to do completely different things, for which my lib wasn't at all optimized or even designed for in the first place. The point is, you really don't know what the app devs will want before they actually want it. And even then much of it actually turns out to be wrong, since they often don't even know it themselves before they've implemented their stuff. Some stuff you can predict with a high level of certainty, but surprisingly much you can't. Therefore you want as much flexibility as possible as late in the game as possible. Committing optimizations to hardware before having all app devs try different software versions of it is not being flexible. It works to some degree for "old" fields, such as CPU, or even GPU, designers (but even there we've seen many, many failures), but not so much for new stuff like e-book interfaces on slowly refreshing displays.
|
Yes, I agree that there is a chance of omitting things that would be useful, and including things that may not be needed. But I've seen this in action vs current controllers vs (unoptimized) software. I'm just trying to say that you may be overly pessimistic. The development has included feedback from the current gen, as well as feedback from a beta program.