Region invalidation malfunctioning after text buffer has begun to scroll #15193

Closed
opened 2026-01-31 04:31:06 +00:00 by claunia · 19 comments
Owner

Originally created by @oising on GitHub (Sep 13, 2021).

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

after selection:
image

Expected Behavior

  • text rendered correctly 💩

Actual Behavior

  • text rendered incorrectly
Originally created by @oising on GitHub (Sep 13, 2021). ### 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. ![image](https://user-images.githubusercontent.com/1844001/133122825-d8f2f2c0-898d-45f3-9fd3-101933a4f004.png) after selection: ![image](https://user-images.githubusercontent.com/1844001/133122881-af658e9b-2bd3-42fa-bad5-03dd24e6f2d9.png) ### Expected Behavior - text rendered correctly 💩 ### Actual Behavior - text rendered incorrectly
Author
Owner

@jessey-git commented on GitHub (Sep 14, 2021):

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.

@jessey-git commented on GitHub (Sep 14, 2021): 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.
Author
Owner

@zadjii-msft commented on GitHub (Oct 7, 2021):

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.

@zadjii-msft commented on GitHub (Oct 7, 2021): 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.
Author
Owner

@oising commented on GitHub (Oct 7, 2021):

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?

@oising commented on GitHub (Oct 7, 2021): 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?
Author
Owner

@oising commented on GitHub (Oct 14, 2021):

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.

image

with selection applied after:

image

@oising commented on GitHub (Oct 14, 2021): 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. ![image](https://user-images.githubusercontent.com/1844001/137347366-5efc7c6a-100a-4fb3-9116-0414f0fca2e4.png) with selection applied after: ![image](https://user-images.githubusercontent.com/1844001/137347480-9d017944-4f84-4b5b-8534-f7d2706fdf14.png)
Author
Owner

@oising commented on GitHub (Oct 14, 2021):

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?

image

scaling is 100% on the external screen. My sb3 is at 200% and native resolution.

@oising commented on GitHub (Oct 14, 2021): 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? ![image](https://user-images.githubusercontent.com/1844001/137349232-8f8c5349-aa65-49b4-a042-62350b2918f8.png) scaling is 100% on the external screen. My sb3 is at 200% and native resolution.
Author
Owner

@jessey-git commented on GitHub (Oct 14, 2021):

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%
2k-100 4k-200
@jessey-git commented on GitHub (Oct 14, 2021): 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% | |---------------|-----------| | ![2k-100](https://user-images.githubusercontent.com/7989986/137375116-aa7637c2-4a34-4c1b-aaba-3f048e6438fb.png) | ![4k-200](https://user-images.githubusercontent.com/7989986/137375127-65c5988a-1afc-4181-b3c7-e59be140e892.png) |
Author
Owner

@jessey-git commented on GitHub (Oct 22, 2021):

Version 1.12.2931.0 remains broken on Win10 for me.

@jessey-git commented on GitHub (Oct 22, 2021): Version 1.12.2931.0 remains broken on Win10 for me.
Author
Owner

@kstange commented on GitHub (Nov 5, 2021):

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.

@kstange commented on GitHub (Nov 5, 2021): 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.
Author
Owner

@oising commented on GitHub (Nov 18, 2021):

In case it's not clear, you can workaround the problem by enabling the "redraw entire screen when display updates" option:

image

@oising commented on GitHub (Nov 18, 2021): In case it's not clear, you can workaround the problem by enabling the "redraw entire screen when display updates" option: ![image](https://user-images.githubusercontent.com/1844001/142486815-3942aa54-fce4-48a1-92be-7ff95a19d90b.png)
Author
Owner

@jessey-git commented on GitHub (Dec 15, 2021):

1.12.2931.0 still broken

@jessey-git commented on GitHub (Dec 15, 2021): 1.12.2931.0 still broken
Author
Owner

@Diu commented on GitHub (Feb 26, 2022):

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

@Diu commented on GitHub (Feb 26, 2022): 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
Author
Owner

@zadjii-msft commented on GitHub (Mar 1, 2022):

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.

@zadjii-msft commented on GitHub (Mar 1, 2022): 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.
Author
Owner

@guhetier commented on GitHub (Mar 14, 2022):

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
@guhetier commented on GitHub (Mar 14, 2022): 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`
Author
Owner

@zadjii-msft commented on GitHub (Apr 8, 2022):

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

@zadjii-msft commented on GitHub (Apr 8, 2022): 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).
Author
Owner

@oising commented on GitHub (Apr 8, 2022):

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.

@oising commented on GitHub (Apr 8, 2022): > 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.
Author
Owner
@zadjii-msft commented on GitHub (Oct 26, 2022): Linking some threads: * #11214 * #11334 * #12805 * possibly also #14530 * #13840 * #14512
Author
Owner

@zadjii-msft commented on GitHub (Aug 15, 2023):

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 commented on GitHub (Aug 15, 2023): 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 😅
Author
Owner

@oising commented on GitHub (Aug 15, 2023):

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

@oising commented on GitHub (Aug 15, 2023): @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?
Author
Owner

@oising commented on GitHub (Aug 15, 2023):

Closed as fixed.

@oising commented on GitHub (Aug 15, 2023): Closed as fixed.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#15193