View Single Post
Old 01-07-2014, 05:32 PM   #16
geekmaster
Carpe diem, c'est la vie.
geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.
 
geekmaster's Avatar
 
Posts: 6,433
Karma: 10773670
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
Quote:
Originally Posted by staylo View Post
Hi geekmaster,

I picked up a DXG recently and I'm still trying to get up to speed on the limitations of the device. In a previous post (https://www.mobileread.com/forums/sho...d.php?t=177455) you mentioned that > 1.5fps was possible on the DX / DXG - any further details on what tricks were used to achieve that, and the update rate obtainable? (apologies if this isn't relevant enough to this thread)
My code that shows how fast it can run one demo in the "newtrix" demo. I used a spatio-temporal random dither (a fancy way of saying every pixel is draw black or white depending on threshold computed from the color value multiplied by a random number. For a given pixel and pixel color, it changes between black on white on successive frames, in a ratio that your eye averages out over time to see it as a gray pixel value exactly as the software intended.

That alone is not enough for speed. You also need to limit the size of the update window, which slows down the update rate when it is larger, and speeds up the update rate when smaller. If you update a small enough area fast enough, it will appear as a sparkly gray value, and with moving, it leaves a pulsating fading trail behind it. That trail appears depends on which kindle model, with the newest models leaving the smallest trails with the least pulsating oscillation. The update window size can be automatically determined by the device drivers in some modes, so do not change pixels outside the active window area between display updates, to keep the update window as small and fast as you can. As I mention before, I believe this is a temporal aliasing artifact with the device drivers.

To see how I coded this effect I have described above, press the "Show" button and look for "sparkle" (eink spatiotemporal dither demo) in the "newtrix" source code:
https://www.mobileread.com/forums/sho...d.php?t=176802

In a DX (slow) or DXG (a little faster eink display type), the demo speeds up as the updated area gets small, and it gets many FPS when that update window is fairly small.

Last edited by geekmaster; 01-07-2014 at 05:35 PM.
geekmaster is offline   Reply With Quote