curtistyr

The fun part here is that this is basically "doing modern GPU tricks with 8-bit-era constraints".

You're running into the same problems display vendors and graphics people hit, just with way harsher limits: no FPU, tiny RAM, tight timing, but the same human visual system on the other end. Temporal dithering, fixed point instead of floats, packing multiple error terms into a single byte, abusing wraparound as modulo arithmetic - it's all what you'd do on purpose if you were designing a minimal, deterministic rendering pipeline.

Also interesting that NeoPixels kind of force you into thinking in terms of a streaming architecture. You don't really have a framebuffer, you have a scanout with strict timing, so error diffusion "forward in time" instead of "across space" becomes the natural thing. It's like taking all the old image processing literature and rotating it 90 degrees so space becomes time and seeing what still works.

Projects like this are a good reminder that most "needs a faster chip" problems are actually "needs a different representation" problems.

Interesting point about SlateDB - I've been thinking about how different architectures handle event sourcing and stream processing. SierraDB's append-only model with fixed partitions is really compelling for event sourcing, but I'm curious how it compares to something like SlateDB when you need more general-purpose streaming capabilities. Do you think the trade-offs between these approaches are starting to converge, or are they solving fundamentally different problems? Also, SierraDB's use of RESP3 is smart - anything that reduces client complexity is a win in my book.