Really nice demos. On my K3, 50% of the CPU time is spent in the Kernel (according to unreliable "top"). Probably, the eink driver could be a bit more optimized...

For the K4 and K5, they eink update calls return immediately, and we have to be careful to not touch the framebuffer until ready, so we wait in a spin-loop. Using a timer to signal an event would save battery in that case, but this is not a long-running background process and that would complicate the code, so a simple spinloop does the job quite nice here.

Dithermatron 1.1 was very fast but from one point it appeared that it was a bit too fast for the screen to keep up.
The cosmegg one was trippy.

Actually, it increases speed while running, and it starts drawing more and more between screen updates, but it does not increase the delay between updates, so at some point the eink drivers cannot keep up and it gets "glitchy". I have another version that I did not post that runs it all at a nice speed (what you would see after the top or bottom of the screen get bumped 10 times. Faster than that and the display updates fall back into "deferred update" mode (which looks rather ugly). I like to run these demos from SSH while in screensaver mode (framework sleeping). Less competition for resources that way and it works nicely for me. Or run it from diags...

You can slow it down by using a different K4DLY selection and recompiling. Cosmegg accepts a command line parameter for msec between display updates. You can change it to 250 for 4 updates/second (./cosmeg 250).

EXPERIMENT: Run multiple "dithermatron &" in the background to see MORE objects.

This started as a test stub to verify the "color palette" dither table values. I now subtracted one from all values so it can get a pure black. Remember that dithering with an 8x8 table gives 65 shades, not 64 as 6-bit colors would give. Anyway, this is an animated "color" palette demo. Not as flashy as the others, but it shows how to use a new function (scaleable palette display). I animate the scaling factor here.

Using this new color palette in some existing programs can make the WHITE value go away, requiring adjustment to the color scale factors in the program.

Remember to clear the screen (eips -c) before running this each time.

The moving palette "wall" appears to be semi-transparent, but that "transparency" is just eink ghosting, which you would not see in a screenshot, but that ghosting looks interesting and contributes to the effect in this demo.

UPDATE: The new paldemo version (not yet published) contains a second dither table with gamma 2.2 dither threshold values for LCD and CRT desktop displays. This gives a color palette screenshot that appears correctly balanced (average 50% gray) on desktop displays. See the gamma tutorial below.

This "paldemo" program demonstrates the new "geekmaster formula 42" dithering function adapted for a 0-255 color palette. It can be used to convert a framebuffer containing a grayscale image or antialiased text directly to dithered black and white, so that it can be animated or resized smoothly.

A new dither table is used that spreads the 65 shades of gray evenly through the 0-255 color value range, and a "-1" adjustment was made to a strategic location in the formula to balance the number of pure blacks and pure whites on the ends of the color table for 4-bit pixel displays.

Because 65 is not a power of 2, the threshold columns do not line up in the displayed 16x16 color palette, but this is to be expected for non-integral range conversion.

The display palette onscreen size is adjustable. This demo program calls palette(550) to display a 550x550 pixel palette, but you can change that value to resize the palette.

The screenshot gamma tutorial:

Spoiler:

This image has a display gamma of 1.0 needed for kindle eink displays (just like printing on paper). CRT and LCD displays are typically adjusted for gamma 2.2, so this screenshot appears as a well-balanced color spread on the kindle, but viewing this on a CRT or LCD panel will show too many brights and not enough darks. That is to be expected, and adds another complication if you want a program to work on both eink and on LCD panels.

The DARK values are strongly affected by the gamma settings. Compare this image on an LCD panel (like you are probably viewing it on now) with the image displayed on a kindle eink display. Pay careful attention to the top five rows. On a kindle eink display, the entire top five rows of this image are black or "almost black".If you do not see what I am describing, your web browser probably converted the image to grayscale (with gamma correction) if it resized the image. View the image at "original size" and then compare it to the same image on the kindle. When viewed at the correct screen size, it will contain ONLY pure black and white pixels.

Gamma adjustments must be made by selecting dither tables with DIFFERENT threshold values for eink and LCD displays. The proper way to take a screenshot is to re-dither the 256-color image using an LCD dither table, and capture that. The image below uses an eink dither table. I will add another screenshot after I build an LCD dither table for my "paldemo" program.

An image dithered with an LCD dither table will look good on this web page, but will look MUCH TOO DARK on a kindle eink display. You need to use a dither table with threshold values that match your intended display device.

Firs of all, thanks for your awesome code, Geekmaster.
I'm a beginner, and I played a bit with your sources. This is a little demo I came up with.

It's alive!

I ran it. It looks like a random walk with pixel timeout and erase. Now I need to go look at the code. This looks interesting. You should add things like a Hilbert Curve to this.

It looks like you pumped the source code through AStyle to reformat it. Unfortunately, AStyle does not have a profile for my condensed coding style that I like (max code per line, max lines per page). White-space lovers probably hate my code anyway. You should change the program name in the comments at the top, and add a revision history that includes your name.

This was worth the "2600 karma" badge of honor. Oops... wrong karma field (I gave you too many points).

WARNING: One thing about the MIT license: This is a derivative of my code, so the copyright FOR THIS SOURCE FILE is still mine. The purpose of the copyright is to support the MIT license so that others can freely use my code, so it does not need multiple copyrights. You removed MY copyright -- you should put that back. It is better to add a revision history to my file to show your name and your changes or additions. If you NEED your own copyright for your function, you should put your function code in a separate .c source file, and put your copyright (and the MIT license or other compatible license such as BSD) in that file. Then link it to mine by putting both files on the compiler command line. I added my original copyright back to the source code (and you should too, and you should edit your post above, to replace the download with a replacement zip file containing properly attributed code. ) Here is the updated code with my copyright line restored (and new title, and additional models tested):

However, I don't think you need to use the dither algorithm because it is all black and white.

Maybe you can modify the demo so it shows dithering...

Thanks,
James

Geekmaster formula 42 does a lot more than just dithering. It works on all eink kindles. It works for 4-bit and 8-bit framebuffers. It works for color 0 = white and for color 0 = black. It works on 6-inch and 9.7-inch displays. It has no branches (if else statements) so it is very fast and cache-friendly. It is fine to use it only for black and white. Dithered gray is just an added benefit.

I have a new modified formula 42 that takes color values 0-255 instead of 0-65, so it can be used directly with 8-bit images with no need to pre-scale the color values. It was published as part of "paldemo". It also works with non-linear dither tables, including a LCD 2.2-gamma table (screenshot provided in paldemo post).

I just ran your version. The dithered grays do look interesting on this demo. I like seeing my code grow in unexpected directions that are not on MY "to do" list.

P.S. I am getting an occasional "sementation fault" error on this, which probably means that it tried to write past the end of the framebuffer (y > 799). Although there is no harm in this for a demo, it SHOULD be fixed in the next version (so this error does not end up in other code that borrowed from this, perhaps causing real damage in some other scenario -- better to just do it right).