terminal
terminal copied to clipboard
microsoft
Performance issue with dragging/animations on latest preview
Windows Terminal version
1.13.10336.0
Windows build number
10.0.22000.0
Other Software
No response
Steps to reproduce
- Open terminal v1.13 in a non-maximized mode
- drag it around your desktop, or click on arrows to show animations
- easier to see with a high refresh rate screen(I use a 144hz one)
Expected Behavior
performance for window dragging and animations shouldn't change over versions
Actual Behavior
When dragging my terminal from version 13+, it seems to be "lagging" terribly. No other software shows this behavior.
I couldn't upload a video to github(file too big, tried to capture at a high refresh rate & resolution so it's more obvious) but here's a gfycat link exemplifying: https://gfycat.com/gargantuanteemingiaerismetalmark Please watch it in HD so that it's clearer to see.
easier to see with a high refresh rate screen(I use a 144hz one)
That might be why I can't seem to see this locally. My only guess is that this is due to #11680, but I sure as heck don't know why that would be, or how we'd even begin to start debugging that.
hi, I figured out some new information
I was using a Freesync screen with Nvidia G-SYNC turned on. When I turned Freesync off, the bug was gone. Must be some weird interaction with the video drivers and *Sync techs. Thinking about it, it definitely feels like the preview terminal is at a "lower framerate".
This doesn't happen with current stable terminal nor with any other windows 11 application, regardless of Freesync status.
Hmm. The Preview build has acrylic in the titlebar, the stable one doesn't. Maybe try disabling that, see if that changes it. I'm trying to think if there are any other settings differences that might make a difference here.
Did you maybe opt the Terminal (stable) out of gsync in the nvidia control panel, but not the Preview build?
@Barbiero Do you have the new "atlas engine" / "experimental text renderer" enabled by any chance? Nvidia's driver has a bug where it really really really wants us to use G-SYNC, even though our application really doesn't. 😄 Since we only draw when something changes (meaning: whenever the cursor blinks), it'll effectively drop the entire monitor frame rate down to 1 FPS (or something close to it), which makes everything stutter. We asked them to include Windows Terminal Preview in their driver exclusion list, but haven't heard back yet.
@zadjii-msft disabling acryllic makes no difference. Also, I did not opt the stable version out of g-sync purposefully: on nvidia control panel, it says that Windows Terminal is not compatible with g-sync at all. The windows terminal preview didn't show up on the list automatically, and when I added it to the software list it was set as "use global configuration (compatible with G-SYNC)".
@lhecker I never enabled anything like that and unfortunately I don't even know how I'd be able to check; web searches provide me no useful information on those terms 😭
Purposefully customizing windows terminal through nvidia control panel in order to make it ignore g-sync fixes the issue, but I feel like that's a very weird workaround.
I guess this is a thing with nvidia not excluding WT Preview version. Thanks for the help all.
@Barbiero I also have a G-Sync monitor and up until now Windows Terminal did not trigger G-Sync. But today we launched Windows Terminal Preview 1.13, which features a new renderer. That one weirdly enough consistently triggers G-Sync for me.
I'll follow up with the Nvidia devs soon and ask them what the status quo for the addition to the exclusion list is. If you have an up to date driver, the non-Preview version of Windows Terminal should already be on the exclusion list and work fine in the meantime. 🙂
Nvidia Profile Inspector:
Given the green line you'd expect it to apply to any executable named "windowsterminal.exe", but nope... In either case it seems to go by the package name.
Wait, the package's actual system-level ID has not changed¹. Are you telling me they're going by the "Visual Element" display name? That would be madness.
¹ We're still Microsoft.WindowsTerminal{,Preview}_8wxxxxxxx... and the package's official display name is still "Windows Terminal{, Preview}"
If they're using the visual element display name, they would need to add one exclusion for every package PER every language that that package supports. Something else must be going on here.