| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
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.
|
| |
|
|
|
|
| |
We'll gradually make this more dynamic.
|
|
|
|
|
|
| |
We now use traces everywhere for error-checking. Null traces introduce
the possibility of changing a functions error response, and therefore its
semantics.
|
| |
|
| |
|
| |
|
|
|
|
| |
We really need to systematically check our trace streams.
|