Hacker News new | ask | show | jobs
by jlokier 2004 days ago
The last time I built something with a small display, the CPU-and-on-board-RAM combo didn't have enough room for a framebuffer. But it did have multiple cores, and each of those had multiple hardware-multiplexed threads for real-time processing. Most of the threads were devoted to audio DSP and maxed out.

It was fun developing a little algorithm to stream out full rendered frames in real time, bit-banging 16-bit colour over SPI at its max frequency, while rendering and compositing from an object tree with fonts, textures, gradients, blending etc without ever storing more than a few scan lines worth of pixels. Intermediate pixels and blending states were stored in an ever-moving queue to account for multi-pass rendering and the different timing between the rendering thread, which blended in each item at whatever speed could be done, and the bit-banging SPI thread which formatted the pixels into the strange bit order needed by the display. The bit-banging thread needed perfect, sustained timing as a single glitch would crash the display.

When all the complications were working perfectly, it just looked like a mundane but smoothly animating display, as if it had a boring GPU and framebuffer and some kind of clean GUI.