We'll need this when rendering 16-bit glyphs. They'll occupy two
8x16 display units on screen, but the grapheme is a single unit as far
as fake screens are concerned.
Font rendering now happens off the real screen, which provides the effect
of double-buffering.
Apps can now also use convert-graphemes-to-pixels for more traditional
double-buffering.
Before: we always drew pixels atop characters, and we only drew pixels
that were explicitly requested.
After: we always draw pixels atop characters, and we only draw pixels that
don't have color 0.
Both semantics should be identical as long as pixels are never drawn atop
characters.
Even if they duplicate lower-level ones, we have an opportunity for better
error messages. Any time I see a hard-to-debug error message, I should
be asking myself, "what higher-level primitive should catch and improve
this error?"
Filling pixels isn't a rare corner case. I'm going to switch to a dense
rather than sparse representation for pixels, but callers will have to
explicitly request the additional memory.
Kartik K. Agaram