Quote:
Originally Posted by jmseight
Hi,
This looks really cool. I only have K3 but it is pretty fast.
So the speed is completely limited by full screen update, correct?
Now you can play videos easily if you put successive frames in the image buffer, correct?
Thanks,
James
|
Yes. We can dither the images MANY time faster than the K3 can return from writing to the update port, or calling eips. But the K3 is capable of faster updates using ioctl() calls, if you limit the "active" part of the screen to a smaller area.
I got about 5 FPS fullscreen, or 12 FPS updating only a 640x360 rectangle (the size of old DivX movies). For "talking heads" video (mostly dialog, like TV talk shows), you just need to update mostly the face area at high speed.
Also, you can pre-filter the video to smooth any changes in time and space (averaging successive frames in a "long persistence" way), and other video filter tricks such as "deshaking". That makes it a LOT more eink-friendly. The key is to minimize (or ignore) unimportant changing areas on the screen, so the eink drivers do not fall behind the video causing nasty (self-correcting over time) display artifacts.
On the K5, you can update as fast as you want, but if you do it too fast the eink drivers can just shut down for your process (white screen). Opening another SSH session and doing eips '' commands shows that the framebuffer is changing, because the NEW process still gets eink requests honored.
It appears that the eink drivers detect "abusive" eink updates and start ignoring requests from that process. So we need to add delays before eink update requests, in some cases.