terminal
terminal copied to clipboard
Region invalidation malfunctioning after text buffer has begun to scroll
Windows Terminal version (or Windows build number)
1.11.2421.0
Other Software
- Windows 11 / 21H2 / 22000.132
Steps to reproduce
- open powershell (could be another shell)
- execute "ls" / "dir" a few times until the text buffer has begun to scroll
Parts (or the entirety) of the buffer should be invisible, yet will be rendered visible if selected with the mouse
e.g.
after selection:
Expected Behavior
- text rendered correctly 💩
Actual Behavior
- text rendered incorrectly
I've also been seeing this since moving to 1.11 preview (usually with various git
commands for me). I didn't notice at all in the 1.10 preview so perhaps a regression.
I've been playing with this all morning and can't seem to get a repro. Frankly I haven't seen this once on the 1.11+ selfhost, and I'm not sure anyone else on the team has either. Not sure how we're going to be able to dig in more here without a at least semi-consistent repro.
I'm gonna move this out of 1.12 into 2.0 for now. If it's more widespread, then maybe that'll help us ID a repro. If it's not, then at least that's a good sign.
My win11 recently updated to 22000.194 (the final release) and I haven't seen it since -- I wonder if it was something more fundamental in the kernel?
Hmm, I spoke too soon -- it's happening again. I'm on win11 22000.258 now, but I don't know if that's anything to do with it. Could it be something to do with colour output? I'm still on 1.11 for terminal.
with selection applied after:
Some more notes:
- when I draw the selection box, I only have to select the first cell to repair the entire line
- it does NOT happen on my laptop's (surface book 3) native display, it only happens on my external screen (lg ultrawide)
Could it be DPI related?
scaling is 100% on the external screen. My sb3 is at 200% and native resolution.
It could very well be DPI/scaling related (also happens over mstsc connections more often too). At least for me on Win10 here. See below as I can make my current terminal show "missing" lines at will by just dragging between the monitors here.
1080p 100% | 4k 200% |
---|---|
![]() |
![]() |
Version 1.12.2931.0 remains broken on Win10 for me.
I've been seeing this on my second display in the last few days. I'm running on a Surface Book (1st gen) and the terminal fails to render lines only if it's on the external monitor (1080p via DP) which is set to 100% scale. The built-in is set to 175% scale 3000x2000 native resolution and is working fine. It loses a LOT of lines during fast scrolling, often more than 50% of them. The behavior described of highlighting them to get them to reappear works the same as other reports. I have version 1.11.2921.0 from the Windows Store, which last updated Oct 29th.
In case it's not clear, you can workaround the problem by enabling the "redraw entire screen when display updates" option:
1.12.2931.0 still broken
Recently got a 4k monitor (150% scaling), and ran into this issue as well on my secondary monitor (FullHD, no scaling). When I disable scaling all lines are rendering just fine.
Version: 1.12.10393.0
This was also reported in MSFT:38160934.
Alas, for the time being, we still don't have any beat on what triggers this.
I don't recall any rendering changes that would have regressed around 1.11, though.... maybe this is fallout from #9820. That's where I'd look first.
I could reproduce this consistently by:
- opening a terminal on one screen
- running
ls
- moving it to another screen with a different resolution
- running
ls
I'm really hoping this was fixed as a side-effect of #12713 (but that hasn't yet been pushed out in a servicing build yet).
I'm really hoping this was fixed as a side-effect of #12713 (but that hasn't yet been pushed out in a servicing build yet).
From my perspective on how it manifests, that looks hopeful for sure.
Linking some threads:
- #11214
- #11334
- #12805
- possibly also #14530
- #13840
- #14512
Hey @oising you still seeing this, like maybe on 1.18/? We've re-written the renderer a couple times since this was filed, I'm thinking this might have gone away on its own 😅
@zadjii-msft Hey Mike! Nope, haven't seen this in a long time. I've got redraw off, s/w off and using the new renderer. I guess close it?
Closed as fixed.