geekmaster dither formula demystified?

[geekmaster]

Originally Posted by staylo

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.

[knc1]

Originally Posted by geekmaster

- - -
Actually, I had hoped that people could use my dither routines pretty much as-is (black box style) by lifting them out of my demos, but perhaps they do need to be packaged better for more widespread adoption by this community.
- - -

Maybe re-write them in COBOL ?

While you where away, we started a project to run, among other things, OS-360 COBOL on your Kindle.

Hmm.... "Mainframe in a padded, zipper, case" or words to that effect.

Note:
Actually what was ported was the Hercules emulator.
And I built up a public repo of the publicly available IBM software.
Including OS-360 and the last public domain COBOL available.

[staylo]

Very useful information and code demos, thanks very much! It's good to know that the display driver is smart enough to determine the quickest draw method between two successive frames, and therefore reducing latency to a minimum (eg when using the DXG as a remote monitor) is a matter of getting the data from the host PC to the framebuffer as quickly as possible.

[twobob]

http://diveintohtml5.info/video.html for general assosciated video information