| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Roll back to commit 70919b45f0. Recent commits add lots of extra function
args for dubious benefit.
|
| |
|
|
| |
Looks like what's slowing down screen rendering is in fact _font_ rendering.
|
| |
|
|
| |
The real screen silently clips coordinates out of bounds.
|
| | |
|
| |
|
|
|
| |
Amazing how much difference it makes even when the implementation is so
naive and slow.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
It causes us to run out of memory during tests.
|
| |
|
|
| |
So far we aren't running out of memory. Might as well loosen our belts.
|
| |
|
|
| |
And we give a high-level error when the pixel buffer fills up.
|
| | |
|
| |
|