Quote:
Originally Posted by seamusfp
Software, particularly software on mobile processors is not going to be able to keep up and provide adequate response.
|
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.)
Quote:
Originally Posted by seamusfp
E Ink does not respond like an LCD, a lot more information needs to be known, kept track of, and processed.
|
Unless it's several tens of bytes per pixel (and I'd be surprised if it was) then I don't see a problem.
Quote:
Originally Posted by seamusfp
As well, this isn't "premature optimization", this is the result of many years of research, engineering, and refinement.
|
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.
Quote:
Originally Posted by seamusfp
I've seen what this controller is capable of, and I am certain this could not be achieved in software on a mobile device.
|
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.
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.