| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
I'm loading them in uncompressed ASCII format, and all streams and gap
buffers all over the place need to get massively scaled up to 256KB
capacity. But the tests don't yet run out of RAM, so I'll keep going.
|
| |
|
|
|
|
| |
One error message gets a bit worse.
|
| |
|
| |
|
| |
|
|
|
|
| |
This is an old 'optimization' that turns out to not actually matter.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two interesting things:
- We don't really need double-buffering for rendering the screen on the
sandbox as a progress indicator. Everything else is untouched, and render-screen
should be doing that as well.
- Rendering just pixels of the fake screen is buttery smooth. It's the
_graphemes_ that are slowing things down. Even though there's so many
fewer of them!
As a result, drawing the fake screen less frequently in `evaluate` doesn't
actually help with flicker. Even though it'll make the debug cycle shorter.
So my current plan is to attack flicker in isolation before I mess with
the render frequency.
In this commit I optimized away the cursor handling. Still doesn't seem
to be helping. In fact it actually seems _worse_.
|
| |
|
|
|
|
|
|
| |
Rename cells containing screens to screen vars because of the ambiguity
that each grapheme in fake screens is represented by a type screen-cell.
While we're at it, we also analogously rename keyboard vars.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Add argument to a few functions.
|
| |
|
|
|
|
|
|
|
| |
I wrote a comment about how some code was not covered by tests, and then
promptly forgot what it was for. This is why we need tests.
Now the hack is gone.
|
|
|
|
| |
We still don't support _any_ fractional literals, positive or negative.
|
| |
|
| |
|
| |
|
|
|
|
| |
Menu shortcut for jumping to function definition.
|
| |
|
|
|
|
| |
Keep hotkeys stable when different elements are in focus.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Since we switched error trace semantics from a designated label to a designated
depth (commit 9831a8cef9 on May 19).
|
| |
|
| |
|
|
|
|
|
|
| |
I was aware of some complications. The various indexes and y coordinates
in the trace's cache would be unstable and need to be recomputed. But it's
surprising that the trace _completely disappears_.
|
|
|
|
|
|
|
|
|
|
|
| |
The goal: the sandbox initially maintains a shallow trace. As you expand
into the trace, the environment reruns the sandbox at greater depth as
needed.
The challenge: expanding happens within edit-trace, which doesn't have
the whole sandbox needed to re-run the sandbox. We'll either need to expand
the trace's capabilities to include the whole sandbox, or duplicate some
logic to decide when to run the sandbox.
|
|
|
|
|
| |
We're soon going to be dynamically rerunning the sandbox in other ways
when browsing the trace.
|