Windows Terminal input is as slow as rubber cement #16088

@zadjii-msft commented on GitHub (Dec 9, 2021):

Hmmm. This might be a core input site bug. That's at least my only theory.

Is typing in the vintage console conhost.exe reasonably responsive?
What about typing in something like the Xaml Controls Gallery, or maybe even the Mail app?

Just trying to narrow down the problem space here. I'm not sure of any other good Xaml Islands applications that have text boxes that we could use for a comparison 😕

@zadjii-msft commented on GitHub (Dec 9, 2021): Hmmm. This might be a core input site bug. That's at least my only theory. * Is typing in the vintage console `conhost.exe` reasonably responsive? * What about typing in something like the Xaml Controls Gallery, or maybe even the Mail app? Just trying to narrow down the problem space here. I'm not sure of any other good Xaml Islands applications that have text boxes that we could use for a comparison 😕

claunia commented

@DHowett commented on GitHub (Dec 9, 2021):

This might be fallout from some of the responsiveness work we've done in Windows 11. Terminal is considered a foreground application, but the console application it is hosting isn't. This may cause some trouble.

If you try to make a text selection when it's bogged down, does that respond at a normal speed? That may help us determine which part of the pipeline is falling down.

@DHowett commented on GitHub (Dec 9, 2021): This might be fallout from some of the responsiveness work we've done in Windows 11. Terminal is considered a foreground application, but the console application it is hosting isn't. This may cause some trouble. If you try to make a text selection when it's bogged down, does that respond at a normal speed? That may help us determine which part of the pipeline is falling down.

claunia commented

@jpage-godaddy commented on GitHub (Dec 9, 2021):

I don't know if this is the exact same thing, but I'm experiencing strangeness when it comes to keyboard input. My computer can get into a state where I get slowness of keyboard input and sometimes repeated characters. Details:

The problem only happens with my wireless keyboard.
The problem isn't there on a fresh reboot; it seems to start happening after some time.
Turning my wireless keyboard on/off does not help.
Restarting the terminal app seems to briefly help but the problem returns quickly.
My wireless keyboard doesn't cause this issue in other apps; it's only this terminal app.
My non-wireless laptop keyboard doesn't have this issue.
It happens for wsl and powershell, though it's much worse in wsl.
It does not happen in conhost.exe.
Text selection is not experiencing the lag.

I'm baffled; sorry to hijack if this is not the same issue as yours @wjk...

@jpage-godaddy commented on GitHub (Dec 9, 2021): I don't know if this is the exact same thing, but I'm experiencing strangeness when it comes to keyboard input. My computer can get into a state where I get slowness of keyboard input and sometimes repeated characters. Details: * The problem only happens with my wireless keyboard. * The problem isn't there on a fresh reboot; it seems to start happening after some time. * Turning my wireless keyboard on/off does not help. * Restarting the terminal app _seems_ to briefly help but the problem returns quickly. * My wireless keyboard doesn't cause this issue in other apps; it's only this terminal app. * My non-wireless laptop keyboard doesn't have this issue. * It happens for wsl and powershell, though it's much worse in wsl. * It does not happen in `conhost.exe`. * Text selection is not experiencing the lag. I'm baffled; sorry to hijack if this is not the same issue as yours @wjk...

claunia commented

@wjk commented on GitHub (Dec 9, 2021):

This might be fallout from the Windows 11 "Foreground Boost" work to make foreground apps more responsive. Terminal is considered a foreground application, but--critically--the console application it is hosting is NOT.

Yep, that’s exactly what’s happening. I can select text and manipulate the app just fine while the input is lagging badly. Is there any way we can make Terminal able to exempt its child process tree from Foreground Boost?

@wjk commented on GitHub (Dec 9, 2021): > This might be fallout from the Windows 11 "Foreground Boost" work to make foreground apps more responsive. Terminal is considered a foreground application, but--critically--the console application it is hosting is NOT. Yep, that’s exactly what’s happening. I can select text and manipulate the app just fine while the input is lagging badly. Is there any way we can make Terminal able to exempt its child process tree from Foreground Boost?

claunia commented

@zadjii-msft commented on GitHub (Dec 13, 2021):

@DHowett I'm having a hard time finding anything on Foreground Boost. You think this is something we'll need to follow up with an internal deliverable to get Terminal/conpty sessions accounted for correctly? Or is there and API we can use?

@zadjii-msft commented on GitHub (Dec 13, 2021): @DHowett I'm having a hard time finding anything on Foreground Boost. You think this is something we'll need to follow up with an internal deliverable to get Terminal/conpty sessions accounted for correctly? Or is there and API we can use?

claunia commented

@riverar commented on GitHub (Dec 13, 2021):

@wjk If you can reliably reproduce this on newer builds of Windows (22489 and higher), can you try reproducing without this boosting enabled? You can fiddle with the feature store to run this test (i.e. vivetool addconfig 36557215 2 and reboot). Don't run this on your main PC and other assorted warnings go here.

For Microsoft: See https://task.ms/36557215 or perhaps look up PriClassNoFgBoost velocity. Should be a good start for your investigation.

@riverar commented on GitHub (Dec 13, 2021): @wjk If you can reliably reproduce this on newer builds of Windows (22489 and higher), can you try reproducing without this boosting enabled? [You can fiddle with the feature store](https://github.com/thebookisclosed/ViVe/releases) to run this test (i.e. `vivetool addconfig 36557215 2` and reboot). Don't run this on your main PC and other assorted warnings go here. For Microsoft: See https://task.ms/36557215 or perhaps look up `PriClassNoFgBoost` velocity. Should be a good start for your investigation.

claunia commented

@wjk commented on GitHub (Dec 13, 2021):

After running vivetool, the Terminal is just as responsive as I would expect it to be given the CPU load.

@wjk commented on GitHub (Dec 13, 2021): After running vivetool, the Terminal is just as responsive as I would expect it to be given the CPU load.

claunia commented

@riverar commented on GitHub (Dec 13, 2021):

I guess that confirms @DHowett's suspicions this is related to new boosting behavior. Thanks for the super quick turnaround. Now to squeeze Microsoft for official docs/guidance... 🤣 (To undo your changes, run vivetool delconfig 36557215 2 and reboot.)

@riverar commented on GitHub (Dec 13, 2021): I guess that confirms @DHowett's suspicions this is related to new boosting behavior. Thanks for the super quick turnaround. Now to squeeze Microsoft for official docs/guidance... 🤣 (To undo your changes, run `vivetool delconfig 36557215 2` and reboot.)

claunia commented

@zadjii-msft commented on GitHub (Dec 15, 2021):

There might be a regression in the OS we've discovered here. I've filed MSFT:37406950 tracking this internally on the kernel team to investigate what's going on here. We'll keep you posted with anything we hear back! (which may be a while with the holidays)

@zadjii-msft commented on GitHub (Dec 15, 2021): There might be a regression in the OS we've discovered here. I've filed MSFT:37406950 tracking this internally on the kernel team to investigate what's going on here. We'll keep you posted with anything we hear back! (which may be a while with the holidays)

claunia commented

@DJankauskas commented on GitHub (Jul 6, 2022):

Is there any movement on this issue? On Windows 11 22H2 I experienced extreme input lag in both Windows Terminal and Visual Studio Code, at least on battery power. Downgrading back to 22H1, along with the viveconfig tip above, seemed to solve the problem, but viveconfig did not help in 22H2. The lag made Terminal downright unusable, and I think it needs to be prioritized before developers are upgraded to 22H2. Personally I found the experience frustrating enough that I was thinking of switching to Linux or MacOS if I couldn't solve the problem.

@DJankauskas commented on GitHub (Jul 6, 2022): Is there any movement on this issue? On Windows 11 22H2 I experienced extreme input lag in both Windows Terminal and Visual Studio Code, at least on battery power. Downgrading back to 22H1, along with the viveconfig tip above, seemed to solve the problem, but viveconfig did not help in 22H2. The lag made Terminal downright unusable, and I think it needs to be prioritized before developers are upgraded to 22H2. Personally I found the experience frustrating enough that I was thinking of switching to Linux or MacOS if I couldn't solve the problem.

claunia commented

@paulboco commented on GitHub (Aug 6, 2022):

I was having the same issue. The issue stopped when I removed the .aws and .azure symlinks from my home directory. Don't know if this is related.
Edit: I spoke too soon. After an hour the sluggish behavior returned.

@paulboco commented on GitHub (Aug 6, 2022): I was having the same issue. The issue stopped when I removed the `.aws` and `.azure` symlinks from my home directory. Don't know if this is related. Edit: I spoke too soon. After an hour the sluggish behavior returned.

claunia commented

@chrisfcarroll commented on GitHub (Oct 19, 2022):

My environment:

Windows 10 21H2
Dell Precision 3551 16GB Core i7
and 'slow as rubber cement' seems a fair description. conhost.exe and other apps are fine.

@chrisfcarroll commented on GitHub (Oct 19, 2022): My environment: - Windows 10 21H2 - Dell Precision 3551 16GB Core i7 and 'slow as rubber cement' seems a fair description. `conhost.exe` and other apps are fine.

claunia commented

@stephenmartindale commented on GitHub (Oct 25, 2022):

+1 on Windows 10 10.0.19044; wt says it's 1.15.2874.0 after I finally worked out how to call up the about dialogue.

I first noticed this with keyboard shortcuts like ctrl+c which are extremely slow – unusably slow, in fact. In some shells – git bash like – it's "slow as in minutes", not just "slow as in laggy".

And, yes, I, too, have noticed that the integrated terminal in vs code exhibits similar behaviour. conhost terminals do not.

@stephenmartindale commented on GitHub (Oct 25, 2022): +1 on Windows 10 10.0.19044; `wt` says it's 1.15.2874.0 after I finally worked out how to call up the *about* dialogue. I first noticed this with keyboard shortcuts like `ctrl+c` which are extremely slow – unusably slow, in fact. In *some* shells – `git` `bash` like – it's "slow as in minutes", not just "slow as in laggy". And, yes, I, too, have noticed that the integrated terminal in `vs code` exhibits similar behaviour. `conhost` terminals do not.

claunia commented

@arymkus commented on GitHub (Oct 25, 2023):

Same issue, awkwardly slow input while typing
Windows 11 21H2 OS build 22000.2538
terminal 1.18.2822.0

GitHub's mintty git bash and vscode's git bash work just fine.

@arymkus commented on GitHub (Oct 25, 2023): Same issue, awkwardly slow input while typing Windows 11 21H2 OS build 22000.2538 terminal 1.18.2822.0 GitHub's mintty git bash and vscode's git bash work just fine.

claunia commented

@rickgladwin commented on GitHub (Mar 20, 2024):

Same issue, very laggy (several seconds) when typing on the command line.
The same issue wasn't happening when using Powershell.
To reproduce:

open Windows Terminal
command wsl (Windows Subsystem for Linux)
open an ssh session to a remote server with localhost port forwarding (ssh -L <local port>:<remote host>:<remote port> <user>@<remote host)
type commands in the remote shell OR use vim in the remote shell (vim lag is even worse)

@rickgladwin commented on GitHub (Mar 20, 2024): Same issue, very laggy (several seconds) when typing on the command line. The same issue wasn't happening when using Powershell. To reproduce: - open Windows Terminal - command `wsl` (Windows Subsystem for Linux) - open an ssh session to a remote server with localhost port forwarding (`ssh -L <local port>:<remote host>:<remote port> <user>@<remote host`) - type commands in the remote shell OR use vim in the remote shell (vim lag is even worse)

claunia commented

@zadjii-msft commented on GitHub (Mar 27, 2024):

@rickgladwin Can you go chime in over at #16861? I think there's possibly a more recent regression in this space that might be relevant.

@zadjii-msft commented on GitHub (Mar 27, 2024): @rickgladwin Can you go chime in over at #16861? I think there's possibly a more recent regression in this space that might be relevant.

claunia commented

@pryorda commented on GitHub (Apr 21, 2024):

@zadjii-msft These versions did not fix the issue for me.

@pryorda commented on GitHub (Apr 21, 2024): @zadjii-msft These versions did not fix the issue for me.

claunia commented

@SpBills commented on GitHub (Oct 28, 2024):

Can confirm this is still a problem. Using Alacritty right now because wt is unbelievably slow.

@SpBills commented on GitHub (Oct 28, 2024): Can confirm this is still a problem. Using Alacritty right now because wt is unbelievably slow.

claunia commented

@zadjii-msft commented on GitHub (Oct 28, 2024):

@SpBills Can you share your Terminal & OS Version?

Honestly this thread might just need to be closed in favor of newer information. I'm worried it's gotten too piled on with a variety of similar symptoms of different root causes.

The renderer has been dramatically rewritten (twice) since 1.11. So perf there shouldn't be an issue anymore?
Is the settings UI also laggy in this scenario? Or just the commandline? That would help ID if this is a foreground boost thing or not
does it only repro when the CPU is under load? or does it repro always?
being on 1.23 (the most recent terminal builds) will probably get the most consistent results

@zadjii-msft commented on GitHub (Oct 28, 2024): @SpBills Can you share your Terminal & OS Version? ---- Honestly this thread might just need to be closed in favor of newer information. I'm worried it's gotten too piled on with a variety of similar symptoms of different root causes. * The renderer has been dramatically rewritten (twice) since 1.11. So perf there shouldn't be an issue anymore? * Is the settings UI also laggy in this scenario? Or just the commandline? That would help ID if this is a foreground boost thing or not * does it only repro when the CPU is under load? or does it repro always? * being on 1.23 (the most recent terminal builds) will probably get the most consistent results

claunia commented

@chrisfcarroll commented on GitHub (Oct 29, 2024):

@zadjii-msft — it could be that the widespread cause is that the Windows Store versions of Terminal are (or were last time I installed) years out of date. That would affect many of us on locked-down corporate desktops.

If so, is there some better place than here to get that addressed?

@chrisfcarroll commented on GitHub (Oct 29, 2024): @zadjii-msft — it could be that the widespread cause is that the Windows Store versions of Terminal are (or were last time I installed) years out of date. That would affect many of us on locked-down corporate desktops. If so, is there some better place than here to get that addressed?

claunia commented

@DHowett commented on GitHub (Oct 29, 2024):

@chrisfcarroll FWIW, the store version of Terminal updates 1-2 weeks after we make a release on GitHub. The current Store version is 1.21.2911.0, which is the latest stable (it came out two weeks ago.)

corporate

That could explain it. Some enterprises do restrict the frequency of updates or the versions available on update.

It is for exactly this reason that we encourage everybody filing bugs or resurrecting years-old bugs to include their version information. That’s why it’s one of the items in the bug template.

As for getting that addressed: I'd recommend talking to your local IT administrator. ☹

@DHowett commented on GitHub (Oct 29, 2024): @chrisfcarroll FWIW, the store version of Terminal updates 1-2 weeks after we make a release on GitHub. The current Store version is 1.21.2911.0, which _is_ the latest stable (it came out two weeks ago.) > corporate That could explain it. Some enterprises do restrict the frequency of updates or the versions available on update. It is for exactly this reason that we encourage everybody filing bugs or resurrecting years-old bugs to include their version information. That’s why it’s one of the items in the bug template. As for getting _that_ addressed: I'd recommend talking to your local IT administrator. ☹

claunia commented

@wilson0x4d commented on GitHub (Jan 5, 2025):

Windows Terminal Version 1.21.3231.0

Recently I noticed that as I typed into a Terminal session there would be intermittent draw artifacts and the delay between what I typed and what I saw appeared significant -- this was annoying. This is why I am here.

As for the draw artifacts, when using pwsh I noticed that autocomplete would fail to draw, every other character might fail to draw (as I typed), and then suddenly everything would draw -- this was distracting as the draw latency could be as much as a full second, or, coincides with my completing typing a statement.

I also noticed that when running a command such as ls the display would lag and then +poof!+ the directory* listing would appear -- this was livable, but obvious.

I then started running some of my development tools and noticed my test runner would incorrectly render test results onto one line, and then when the test runner exited +poof!+ the test results would be correctly rendered on individual lines as expected.

I played with the Direct2D vs Direct3D rendering options and both had the same problem, it was less-pronounced with the D3D render setting but still present. After enabling "Use Software Rendering (WARP)" the problem appears to be resolved +knocks on wood+. I was moments away from ditching Windows Terminal and going back to using tmux in a classic "Windows Console" and WSL for everything, which has its obvious drawbacks.. and to be blunt I will likely do if this problem emerges again.

Hopefully this info helps someone else out there work around the issue if they're experiencing unacceptable latency and render artifacts.

As for fixing this problem in the Product itself, the Product appears to have a design flaw. I am using Windows 11 24H2 26100.2605, all updates applied on a Core i9, w/64GiB ram and a "mid" RTX 4070 Ti GPU -- obviously this is overkill galore for a Terminal program to not be working correctly... I usually do all my development work in Qubes OS which despite the HV overhead and Xen channels wedged in between everything I've never experienced latency anywhere close to what Windows Terminal is exhibiting. VSCode terminal windows works fabulous, Windows Console works fabulous, this is squarely a problem with how Windows Terminal renders.

<3 good luck

@wilson0x4d commented on GitHub (Jan 5, 2025): **Windows Terminal Version 1.21.3231.0** Recently I noticed that as I typed into a Terminal session there would be intermittent draw artifacts and the delay between what I typed and what I saw appeared significant -- this was annoying. This is why I am here. As for the draw artifacts, when using pwsh I noticed that autocomplete would fail to draw, every other character might fail to draw (as I typed), and then suddenly everything would draw -- this was distracting as the draw latency could be as much as a full second, or, coincides with my completing typing a statement. I also noticed that when running a command such as `ls` the display would lag and then +poof!+ the directory* listing would appear -- this was livable, but obvious. I then started running some of my development tools and noticed my test runner would incorrectly render test results onto one line, and then when the test runner exited +poof!+ the test results would be correctly rendered on individual lines as expected. I played with the Direct2D vs Direct3D rendering options and both had the same problem, it was less-pronounced with the D3D render setting but still present. After enabling "Use Software Rendering (WARP)" the problem appears to be resolved +knocks on wood+. I was moments away from ditching Windows Terminal and going back to using `tmux` in a classic "Windows Console" and WSL for everything, which has its obvious drawbacks.. and to be blunt I will likely do if this problem emerges again. Hopefully this info helps someone else out there work around the issue if they're experiencing unacceptable latency and render artifacts. As for fixing this problem in the Product itself, the Product appears to have a design flaw. I am using Windows 11 24H2 26100.2605, all updates applied on a Core i9, w/64GiB ram and a "mid" RTX 4070 Ti GPU -- obviously this is overkill galore for a Terminal program to not be working correctly... I usually do all my development work in Qubes OS which despite the HV overhead and Xen channels wedged in between everything I've never experienced latency anywhere close to what Windows Terminal is exhibiting. VSCode terminal windows works fabulous, Windows Console works fabulous, this is squarely a problem with how Windows Terminal renders. <3 good luck

claunia commented

@lhecker commented on GitHub (Jan 6, 2025):

What you experienced was most likely either:

(Most likely) You had a Direct3D application running that behaves like video game. Windows 24H2 has has a severe composition bug that causes applications like Windows Terminal (or Discord, etc.) to freeze just like how you described it. You can follow this issue: #18040.
A Nvidia driver bug. Those happens from time to time... With such a modern GPU I think it's best to make sure you always use the latest driver straight from Nvidia: https://www.nvidia.com/en-us/geforce/drivers/
This is because the driver package also contains firmware updates. If it still occurs then, I'd reboot once such a bug still happens (that should reset its state).
(Least likely) You had G-Sync engaged for some reason without noticing it and you're using an old Nvidia driver. Nvidia has a bug where it mistakes any application like Windows Terminal (= windowed "iflip" swap chain) as a video game that wants G-Sync and so everything stutters. But you would've probably noticed that because your cursor would've stuttered as well.

@lhecker commented on GitHub (Jan 6, 2025): What you experienced was most likely either: * (Most likely) You had a Direct3D application running that behaves like video game. Windows 24H2 has has a severe composition bug that causes applications like Windows Terminal (or Discord, etc.) to freeze just like how you described it. You can follow this issue: #18040. * A Nvidia driver bug. Those happens from time to time... With such a modern GPU I think it's best to make sure you always use the latest driver straight from Nvidia: https://www.nvidia.com/en-us/geforce/drivers/ This is because the driver package also contains firmware updates. If it still occurs then, I'd reboot once such a bug still happens (that should reset its state). * (Least likely) You had G-Sync engaged for some reason without noticing it and you're using an old Nvidia driver. Nvidia has a bug where it mistakes any application like Windows Terminal (= windowed "iflip" swap chain) as a video game that wants G-Sync and so everything stutters. But you would've probably noticed that because your cursor would've stuttered as well.

claunia commented

@JohnAZoidberg commented on GitHub (Aug 2, 2025):

I'm also experiencing slow input in Terminal when another Terminal window is compiling a big project, leading to 70% CPU usage.
I'm only running a Visual Studio, Edge and Terminal on a Framework Desktop (no nvidia, no gsync).
Terminal 1.22.11141.0

@JohnAZoidberg commented on GitHub (Aug 2, 2025): I'm also experiencing slow input in Terminal when another Terminal window is compiling a big project, leading to 70% CPU usage. I'm only running a Visual Studio, Edge and Terminal on a Framework Desktop (no nvidia, no gsync). Terminal 1.22.11141.0

claunia commented