Quote:
Originally Posted by kaminkatze
Now I'm nearly convinced that I can't come up with any shell script that updates the full 600x800 in a few seconds.
|
The speed problem isn't just the shell script. A LOT of time is consumed by the eink display drivers, especially with the default update mode used by the eips command. You have more control using ioctl() calls from a C program, but even then, if the "dirty area" between update calls is too large, the drivers switch to a "deferred update" mode where they preferentially draw black pixels, but delay drawing white pixels for up to two seconds. They can also detect and update two smaller "dirty" areas inside a larger area.
When you do a LOT of fast updates, the eink drivers create some interesting time-domain artifacts on the display, as an emergent property of the mix of update algorithms they use to blend speed and quality in an algorithmic sort of way.
To get any kind of speed for animation playing in an active window on the screen, I had to make my window about 360x240 pixels (think old-school DivX movies
). Any larger and the display updates become unpleasant for animation.
I found that the best thing to do is use only black and white pixels, with spatial dithering to create perceived grayscale in images. There are trade-offs all around, and it is necessary to adjust your program to compensate for them.
Display updates will be a lot more predictable when I can replace the kernel mode eink drivers with my own code that talks directly to the bare eink controller chips (in a custom u-boot image to begin with, and later in a custom linux kernel). I can now run custom u-boot image files with MfgTool, and custom kernel image files with kexec (see other threads).
Again, we are only limited by our imaginations.
P.S. On the K3, eips is MUCH slower than on the K4 and Touch, so you should call it only in the outermost loop (perhaps updating the entire screen, in some cases, instead of individual cell updates). You really need to try different update speeds to see which works best. In one of my programs, I examine a timer variable in my main program loop, and only do display updates about 5 to 12 times per second using ioctl() calls on a K3 (whatever gives the most pleasing effect for the amount of screen changes I am using). I have not gotten ioctl() calls to work right on the K4 or touch yet, but eips is MUCH faster on them, so I even call it with system("eips ''); calls from C programs, and I did not get ioctl() calls working right on the newer kindles yet (no urgency).
