Skip to content
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

Closed
Tyriar opened this issue Oct 28, 2020 · 8 comments
Closed

terminal.integrated.typeaheadThreshold default value is pretty aggressive #109586

Tyriar opened this issue Oct 28, 2020 · 8 comments
Assignees
Labels
*as-designed Described behavior is as designed polish Cleanup and polish issue terminal Integrated terminal issues terminal-local-echo Relating to the terminal's local echo and line editing for remote windows

Comments

@Tyriar
Copy link
Member

Tyriar commented Oct 28, 2020

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.

@Tyriar Tyriar added polish Cleanup and polish issue terminal Integrated terminal issues labels Oct 28, 2020
@Tyriar Tyriar added the terminal-local-echo Relating to the terminal's local echo and line editing for remote windows label Oct 28, 2020
@connor4312
Copy link
Member

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.

@Tyriar
Copy link
Member Author

Tyriar commented Oct 28, 2020

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.

Once it turns on, it stays on until the latency drops to half the threshold value.

Sounds great 👌

@connor4312
Copy link
Member

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.

@Tyriar
Copy link
Member Author

Tyriar commented Oct 28, 2020

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.

@connor4312
Copy link
Member

connor4312 commented Oct 28, 2020

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 🙂

@Tyriar
Copy link
Member Author

Tyriar commented Oct 28, 2020

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 🙁

@Tyriar Tyriar closed this as completed Oct 28, 2020
@Tyriar Tyriar added the *as-designed Described behavior is as designed label Oct 28, 2020
@Tyriar
Copy link
Member Author

Tyriar commented Oct 28, 2020

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.

@connor4312
Copy link
Member

I'll bump it up to 30ms though to be a little less aggressive

@github-actions github-actions bot locked and limited conversation to collaborators Dec 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
*as-designed Described behavior is as designed polish Cleanup and polish issue terminal Integrated terminal issues terminal-local-echo Relating to the terminal's local echo and line editing for remote windows
Projects
None yet
Development

No branches or pull requests

2 participants