For the K5(touch) it depends mostly on high contrast transitions and how large they are. It analyzes the screen changes and does different things depending on how much of the screen changed since the last update. The most annoying is a deferred update mode, where it stacks many unfinished partial updates, then leaves a trail of up to 32 (an estimate based on observation) dirty rectangles trailing a moving high-contrast object.
If I do low-contrast animation where there are now high-contrast sharp edges, I can do aobut 12 FPS, but for normal content (allowing a little artifacting) I get about 5 FPS.
It helps to NOT write to /dev/fb0 until just before the eips command (or ioctl() if you got that working). I completely redesigned my dithering code, and in my new code. I am now doing all my updates to /tmp/wb0 (an 8-bit virtual framebuffer) at about 30 FPS in 256-color grayscale, then periodically (slow enough to not cause nasty eink display artifacts such as tearing or smearing) I dither that /dev/fb0. Depending on content I can update the display between 4 FPS and 12 FPS (or faster in some cases, with carefully controlled content).
Actually, it seems that the K4 booted from main is FASTER than the K5 for animation (using hybrid K3 eink drivers in 8-bit framebuffer mode).
I will post a little demo showing the maximum speed I have been able to achieve on the K5 using carefully controlled content. Of course, that only works with that special content, and I have to slow down to 4 or 5 FPS updates for normal high-contrast stuff to reduce display artifacts.
I will add a link here to my demo when I post it.
