Pixel-Perfect by Construction
A story about awkward ratios, symbolic case lattices, and why integers still win
There’s a moment in every graphics engine where you think:
“This is probably correct.”
And then there’s the moment when you know it is.
This week I crossed that line.
PixelPlex — my integer-based, symbolically-specialized blitting engine — just passed 100% of its full combinatorial verification space. Not a friendly subset. Not “typical sizes.” The whole thing.
Including the awkward ones.
Including the ones that normally hide rounding bugs.
Including the ones that only fail when clip regions, scaling ratios, and thread slicing line up just wrong.
And that didn’t happen by accident.
The problem with “it looks right”
Graphics code is deceptive.
You can scale an image, clip it, render it, and everything looks fine. But visual correctness is a weak signal. Your eye is very forgiving — your GPU less so — and your users least of all.
Most image engines rely on floating point math and hope rounding error behaves.
PixelPlex does not.
PixelPlex uses a fully integer Digital Differential Analyzer (DDA) to map destination pixels to source pixels. No floats. No drift. No platform variance.
That gives you deterministic scaling:
sx = floor(dx * sd / dd)
But writing that formula is easy.
Making it correct under:
-
clipping
-
arbitrary ratios
-
multithreading
-
upside-down coordinate systems
-
and seam slicing
…is not.
Enter the awkward sizes
Friendly ratios like 512 → 256 hide bugs.
But 817 → 490 does not.
Neither does:
-
1361 → 816
-
817 → 1361
-
490 → 816
-
1361 → 490
These sizes create remainder patterns that force your DDA to make hard decisions:
-
when to carry
-
when to increment
-
when to skip
If your phase is wrong by even one step, the error shows up deep in the image — not at the edges.
That’s where most blitters quietly fail.
The idea: encode the source coordinates into the pixels
Instead of guessing whether a pixel came from the right place…
I encoded the source coordinates into the pixel values themselves.
Each source pixel contains:
R = x low byte
G = x high byte
B = y low byte
A = y high byte
So after a blit, I can decode every destination pixel and ask:
“Where did you come from?”
No heuristics. No image diffing. Just math.
But random testing isn’t enough
Random fuzzing is great for exploration.
But I wanted proof.
So I built something new.
CaseSpace: turning combinatorics into a lattice
PixelPlex has multiple dimensions:
-
source shape (Square / Wide / Tall)
-
destination shape
-
width relation (< = >)
-
height relation (< = >)
-
source rectangle
-
clip mode
That’s not a list. That’s a space.
So I built CaseSpace — a mixed-radix symbolic case generator.
Each dimension becomes a digit.
Each digit has its own alphabet.
Each combination gets a unique integer ID.
So instead of:
“Sometimes this breaks…”
I get:
“CASE 405 failed. Re-run with id=405.”
That changes everything.
The first run: friendly sizes
With power-of-two sizes, everything passed.
Good sign — but not proof.
The second run: awkward ratios
That’s where things got interesting.
I started seeing failures like:
expected (205,203) but got (204,203)
CASE 405: srcShape="Square" dstShape="Square" wRel="<"; hRel="<"; srcRect="Whole" clip="Within"
One pixel off.
Only in X.
Only under certain ratios.
Only inside the image.
That’s exactly the kind of bug that ships.
The real culprit: a missing phase seed
After instrumenting both the expected DDA and the runtime DDA, the answer became obvious:
The slice engine was resetting the X remainder to zero at thread boundaries.
So the carry schedule shifted.
Which meant the source coordinate drifted.
Which meant the wrong pixel was sampled — but only at certain columns.
It was invisible unless you looked for it.
One line fixed it:
se.x := P.se.x;
That was it.
But without CaseSpace, I would never have found it.
The final run: full lattice
With the fix in place, I ran the entire CaseSpace lattice.
All shapes.
All ratios.
All clip modes.
All threading paths.
And it passed.
100%.
Every pixel mapped exactly where the math said it should.
Seams aligned.
Threads agreed.
Remainders propagated correctly.
No drift. No cracks. No ghosts.
Why this matters
Most image engines rely on:
-
floating point math
-
heuristic testing
-
visual inspection
-
and hope
PixelPlex now relies on:
-
integer math
-
symbolic specialization
-
deterministic mapping
-
and formal verification
It behaves like a GPU rasterizer — but runs on the CPU.
And it proves its own correctness.
Closing thought
This wasn’t just a bug fix.
It was a demonstration of a philosophy:
If your system has structure, you can enumerate it. If you can enumerate it, you can verify it. If you can verify it, you can trust it.
And sometimes, the fastest way to perfect an image engine…
…is to teach it how to count.
CaseSpace: Deterministic Combinatorics for Testing Without Randomness