Quote:
|
Originally Posted by dave2008
hi geekmaster,
I saw your reply for gnuboy-kindle and I am interested in how you measured those FPS. Could you please give me some hints?
Kind Regards,
dave
|
In the gnuboy thread I have a link to a page with a vidtest program that I wrote. It is binary only. My source code is full of commented out code and not ready to publish.
I actually use a timer and control when I do a "frame update" command. If I do updates faster than 12 FPS, the screen gets all messed up because of the eink device drivers using a "deferred update" mode that make parts of the screen not get updated until you slow down how fast it is being changed.
And the 12 FPS is only for a partial screen update (about 400x300). Full screen updates can only go about 5 FPS (again by viewing the visible results while controlling the speed of updates). Faster updates makes the screen quality too low to use.
These speeds are for changing only pure-black and pure-white pixels. Grey pixels are MUCH slower to change because they go through a "black->white->grey" cycle (sort of a localized full flash update).
And the drivers treat writing black pixels with higher priority than white pixels.
The big deal is that sending an update command makes the drivers NOT FINISH the update already in progress, and they try to combine parts of screens to figure out what the FINAL image will look like and do that when things are changing fast. This really messes up any animation. You can avoid that by slowing things down...
What I do for onscreen image rotating and resizing is to convert grayscale images to dithered black-and-white when two fingers touch the screen, then do rotations and resizes with finger rotate, pinch and stretch motions. I also do those operations to the hidden full grayscale image and then display that on finger release.
I am currently having issues with the kindle touch reporting wrong finger coordinates after they cross a common vertical or horizontal line white rotating. Trying to sort that out before I publish anything significant in this area...
And yes, there are temporal screen artifacts during updates. Another way to see them is using gnuboy to run the "Boulder Dash" game ROM. During parts of the game when only the main character is moving it is fine, but when it is smooth-scrolling the entire screen things start to "smear" badly. The smears are not hardware, but rather the eink drivers updating black pixels quickly but taking many screen updates before they get around to drawing white pixels. They could catch up more quickly if the game did not use all those changing animated game tiles.
You need to adapt your visual content to work around the eink device driver behavior (designed for quick ebook page turns), or you need to write your own eink device drivers (designed for pixel animation).
(Regarding my announced "vacation" -- I am getting a LOT of family pressure to "get on with it"... So do not be surprised if I stop posting here for long periods of time). But it is SO MUCH FUN to continue to feed my Kindle addiction...
