diff options
Diffstat (limited to 'features.txt')
| -rw-r--r-- | features.txt | 17 |
1 files changed, 17 insertions, 0 deletions
diff --git a/features.txt b/features.txt index e05f6f07..5583e7f3 100644 --- a/features.txt +++ b/features.txt @@ -139,3 +139,20 @@ tracing and the GPU/driver stack coming up, and the only lever on either is the The Last builtin should fall back to a heuristic when the jumplist has nothing to offer, so the bare tty layout -- a shell with an unfocused text pane under it -- alternates with Last even though that text pane was never focused and is not on the jumplist. + +Before finishing: remove the zig cache, then build ReleaseSafe with the full tree-sitter options, install to ~/.local/bin, and make sure the desktop entry and anything else that launches +pardes point at the updated binaries. + +Design smell, and it is a real one: Pardes.pump serialises input, event processing, 9P servicing, rendering and presenting into one loop, so the frame rate ends up +governing things that have nothing to do with drawing. The frame rate should only govern rendering. Evidence: a 9P RPC against an idle gui session costs 19.6 ms +and ZERO editor CPU -- it is not doing work, it is sleeping out the 16 ms SDL_WaitEventTimeout because the cross-thread wake does not wake it, and 9P is only +serviced afterwards in poll_frame. The same RPC against a tty session, same cloud9 runner, is 0.758 ms. So the server is fine and the gui host loop is the problem. + +Caching optimisations for the gui: worth doing, the renderer rebuilds more per frame than it needs to. + +FIXED, and it was the frame coupling after all: pump now draws a frame only when something that can change the screen happened. Pardes.needs_frame starts true, +is set by every event except a tick with nothing animating and a read-only fs_req, and is cleared once a frame is presented; pump returns before render/present +when it is false and nothing is animating. 9P round trip on a local socket: gui 9.7 ms -> 0.056 ms (173x), tty 0.758 ms -> 0.062 ms (12x). The wake path was never +the problem -- instrumentation proved every request woke the loop early (wakes=210, woke_early=212, timed_out=38 over 250 ticks) -- the reply simply could not be +produced until the loop had finished drawing a frame it did not need. Verified the gui still paints (screen shows the file, and a write through 9P redraws) and +the full suite is unchanged at 778/783 with the two known crashes. |