Bufferless
BUFFERLESS EPD PROCEDURES (COMMANDS)
Why Bufferless Commands Need Padding Parameters
Before working through the individual bufferless commands, it's worth understanding why so many of them — EpdPixel(), EpdByte(), EpdNPixel(), Epd2Pixel(), EpdNCrossPixel(), EpdLineHN(), and others throughout this section — carry bLeftColor/bRightColor (and sometimes bMiddleColor) parameters at all.
This isn't incidental API design; it's a direct, unavoidable consequence of two facts already covered earlier in this manual:
Combine these two facts and the problem becomes clear: whenever you want to draw something that doesn't happen to start and end exactly on an 8-pixel byte boundary, the byte you send also determines the state of whatever other pixels happen to share that byte — and because there's no read-back, there's no way to quietly "preserve whatever was already there." The library has no way to know what was there.
You have to tell it explicitly what those other pixels should become.
That's what bLeftColor and bRightColor are for: they let you specify what color to write into the portion of the byte that falls outside your intended pixel or line, on whichever side(s) apply.
Some functions also expose a bMiddleColor, for the case where two separate points fall within the same byte and there's a gap of untouched bits between them that also needs an explicit value.
A concrete example: say you want to set a single pixel to black, and that pixel happens to be the 3rd bit position within its byte.
The write still has to send a full 8 bits. If you specify bLeftColor = WHITE and bRightColor = WHITE, the resulting byte correctly shows your one black pixel surrounded by white on both sides.
If you get this wrong — or worse, forget to think about it at all — you're not just failing to draw your intended pixel correctly; you're actively overwriting whatever content the other 7 pixels in that byte were supposed to show, silently corrupting anything else sharing that byte, possibly content from a completely different shape drawn moments earlier.
This is specifically a bufferless-mode concern. In buffered mode, none of this applies — the full frame buffer lives in RAM/SRAM, where existing pixel data genuinely can be read back and merged with new content before anything is ever sent to the display.
That's why TFT-style buffered functions like TftPixel() need no padding parameters at all, while their bufferless counterparts do: the two modes are solving the same drawing problem under very different constraints, and the API shape of each reflects that directly.
Keep this in mind as you go through the individual command entries that follow — every bLeftColor/bRightColor/bMiddleColor parameter you'll see is answering the same underlying question:
what happens to the pixels I'm not explicitly trying to draw, but which share a byte with the ones I am?
Most EPD libraries avoid this problem by using at least a partial frame buffer internally, even when advertised as memory-efficient.
This library's bufferless mode is a genuine zero-buffer alternative, which is why these parameters exist — there's no buffer left to hide the bookkeeping in.
This is also the library's first release, and given the genuine complexity of the logic involved — and that this is a free hobby project built in my spare time rather than a commercially resourced effort — some anomalies are unavoidable.
If you run into something that doesn't look right, please report it on the Positron Compiler Forum.
Created with the Personal Edition of HelpNDoc: Transform Your Documentation Process with HelpNDoc's Project Analyzer