-
Notifications
You must be signed in to change notification settings - Fork 30.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
terminal.integrated.typeaheadThreshold default value is pretty aggressive #109586
Comments
The idea for that was to kick in at "60fps" to increase fluidity in the terminal when it could be perceived, even if it's not slow enough that a user consciously notices a delay. Once it turns on, it stays on until the latency drops to half the threshold value. |
For near 60fps though it adds some visual noise, especially when using dim. If we switched the default to underline we can probably keep the aggressive default though as it's very hard to perceive the single frame where the cursor rectangle changes to an underline, compared to the letter printing in 2 colors.
Sounds great 👌 |
I think bumping up the default (to maybe 30ms?) would be fine. Personally I find the dim much more attractive than underline. But I don't feel strongly either way. |
I suggested 100 since even at 50ms on WSL it's enabled, It really only shines on higher latency situations, for WSL it looks like it takes additional time to draw the character as moving the cursor with a "gap" before it (not long enough for my eyes to register the dim char) looks worse than when the feature is disabled. For underline I remembered what you said about Windows support being bad and experienced it myself so let's stick with dim. |
For me I've kept the setting at 0 to dogfood and actually really appreciated the influence in fluidity even when sshing to the home server on my local network. I don't really see the dimmed characters unless I looked for them, but it make the terminal appear noticeably more responsive comparing side by side. I'm not sure if there've been any studies on it, but there's a history of anecdata of complaints when typing latency gets above 50ms (eg) and praise when it's lower (eg). A lower threshold here could serve as one bit of spice to make Codespaces (even more!) pleasant to use. Imo being enabled if WSL has a 50ms latency is a feature, not a bug 🙂 |
Let's keep as is for now, I guess I can have the best of both world by setting to use underline locally as I typically only remote into non-Windows machines. Just a shame conpty or pwsh or something messes with it 🙁 |
Oh yeah, underline isn't supported in the webgl renderer, that's why it's not working when I try that 😖. Another good reason against underline. |
I'll bump it up to 30ms though to be a little less aggressive |
15ms seems a little aggressive as it even kicks in for local WSL where latency isn't an issue at all. Maybe 100 is a better default? I'm not sure how often this is re-evaluated but we also want to make sure it doesn't keep flipping on and off for a session where latency may vary.
The text was updated successfully, but these errors were encountered: