An interesting observation: My video player uses a 130 msec update rate (about 7.7 FPS). I determined that as an optimal speed (as fast as we can go without excess visual artifacts). The docs I had seen at that time said the update rate was 300 msec, so I seemed to be pushing it faster than was its intended speed. However, I just noticed this page at freescale (mfg of SoC with embedded eink controller):
Quote:
|
Dithering Implementation for Eink Display Panel
...
2. Eink display panel characteristic
a. Low resolution
Eink only has couple resolution modes for display
DU (1bit, Black/White)
GC4 (2bit, Gray scale)
GC16 (4bit, Gray scale)
A2 (1bit, Black/White, fast update mode)
b. Slow update time
For 800x600 panel size (per frame)
DU 300ms
GC4 450ms
GC16 600ms
A2 125ms
3. Effect by doing dithering for Eink display panel
a. Low resolution with better visual quality
By doing dithering to the original grayscale image, we can get better visual looking result. Even if the image becomes black and white image, with the dithering algorism, you will still get the feeling of grayscale image.
b. Faster update with Eink’s animation waveform
Since the DU/A2 mode could update the Eink panel faster than grayscale mode, with dithering, we can get no only the better visual looking result, but also we can use DU/A2 fast update mode to show animation or even normal video files.
...
Currently, with Atkinson dithering algorism, our processing time is about 70ms.
5. 5. Availability
a. We implemented both Y8->Y1 and Y8->Y4 dithering with the same dithering algorism.
b. Implemented into our EPDC driver with i.MX6SL Linux 3.0.35 version release.
c. Also implemented in our Video for Eink demo
|
Notice how they say the pure black/white mode (which we use in gmplay) can do 125 msec per frame (slightly faster than we do here). However, this code was also optimized to work on the K3 (and to some degree on the DX/DXG), which has a slower frame rate. So my tests actually found the right speed, and going much faster would cause noticeable annoying visual artifacts even on newer kindles.
When the K4 and K5 came out, the existing firmware and sourcecode first hinted at an animation more, though there was no code at that time to go with such comments. This linked page above says that eink drivers (for newer kindles) now contain (Atkinson) dithering code built into the eink driver. However, the K3 and earlier (and perhaps even the K4, due to its K3 emulation mode used when booting from the main partition) most likely do NOT contain dithering code (though exanimation of recent source code could see if this was added since I last studied the source code in detail).