Windows Terminal input is as slow as rubber cement

[wjk]

Windows Terminal version

1.11.2921.0

Windows build number

10.0.22000.318

Other Software

My environment:

• VMware Fusion version 12.1.1
• macOS Monterey 12.0.1
• 2.2 GHz 6-Core Intel Core i7 CPU (as reported by About This Mac)
• 16 GB host memory

The virtual machine specs:

• 4 cores (the Windows 10 minimum)
• 8 GB RAM

Steps to reproduce

I am currently running the Visual Studio installer in this VM, placing it under heavy load (100% CPU utilization in Task Manager). If I type anything when the machine is this loaded, the input response time is unusably slow. It is so slow that if I alt-tab away from the terminal, I worry that my inputs might be sent to another program because the terminal hasn't processed them yet. Not being able to alt-tab away after typing a command is a serious productivity blocker for me.

Expected Behavior

The input latency being as fast as any other program on the VM at this heavy a load. (Try filling out a bug report form in Microsoft Edge under these circumstances, like I'm doing. The input latency there is as fast and as responsive as I expect.)

Actual Behavior

Enough time for me to enter a complete command line before the first character appears onscreen. The arrow keys, Backspace, and Ctrl+C are also processed this slowly. (I am a fast typist, but my hand-eye coordination isn't what it used to be; I make many typos while writing text.)

[zadjii-msft]

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 😕

[DHowett]

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.

[jpage-godaddy]

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...

[wjk]

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?

[zadjii-msft]

@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?

[riverar]

@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.

[wjk]

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

[riverar]

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.)

[zadjii-msft]

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)