feat(tui): let the console driver be chosen, and measure what a repaint costs - #3
Merged
Conversation
…nt costs Typing into the editor is slow on Windows with the tool running locally, which rules out the link and leaves the repaint itself. Terminal.Gui redraws the whole screen for every inserted character, and what that costs depends entirely on how the driver hands it to the console - a cost that is far higher per call on Windows than on a Unix pty, and one that cannot be measured from here. So make it measurable and changeable where it matters: tait-codeplug tui --driver list what this platform offers tait-codeplug tui --bench time one repaint on the default driver tait-codeplug tui --bench --driver ansi tait-codeplug tui --driver ansi radio.m8p Terminal.Gui ships three drivers (windows, ansi, dotnet) and picks one per platform. The pick is now overridable, and --bench reports the screen size, the driver and a median over 30 repaints, so the quickest one for a given console can be found in about a minute rather than guessed at. The benchmark has to run inside the application loop: outside it the driver is not live, the terminal has not answered the size query, and a draw costs nothing because nothing reaches the console. The first version measured 0.0 ms against a 0x0 screen, which is exactly the sort of number that looks like good news. For scale, on Linux in tmux at 100x30: ansi 17.7 ms, dotnet 8.5 ms per repaint. Both feel instant. If the Windows driver comes out in the hundreds, that is the whole complaint, and switching driver is the fix. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FkDFej82QnbjMJYFcwYyAZ
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are running the win-x64 binary locally on Windows, in both PowerShell and cmd, and typing into the editor is still 1-2 seconds a character. That rules out the link, which was my previous theory, and leaves the repaint itself: Terminal.Gui redraws the whole screen for every inserted character, and what that costs depends entirely on how the driver hands it to the console. Per-call console cost on Windows is far higher than on a Unix pty, and which of Terminal.Gui's three drivers is quickest there is not something I can settle from a Linux box.
So this makes it measurable and changeable on the machine that has the problem.
--benchprints the screen size, the driver, and a median over 30 repaints. A repaint is exactly what one typed character costs, so that number is the thing you are feeling. Under about 30ms is instant; a few hundred milliseconds is the sluggishness.For scale, this machine (Linux, tmux, 100x30):
ansi17.7 ms,dotnet8.5 ms. Both instant. Ifwindowscomes out in the hundreds on your console, that is the entire complaint and the fix is a different driver.One implementation note worth keeping: the benchmark has to run inside the application loop. Outside it the driver is not live, the terminal has not answered the size query yet, and a draw costs nothing because nothing reaches the console - the first version cheerfully reported 0.0 ms against a 0x0 screen.
86 tests, up from 77: the argument handling (default stays the library's choice, names are case-insensitive, a typo lists the options rather than silently falling back).
Merging this wants a
v0.8.0tag; the CHANGELOG section is written.🤖 Generated with Claude Code
https://claude.ai/code/session_01FkDFej82QnbjMJYFcwYyAZ