terminal icon indicating copy to clipboard operation
terminal copied to clipboard

Region invalidation malfunctioning after text buffer has begun to scroll

Open oising opened this issue 3 years ago • 16 comments

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

oising avatar Sep 13 '21 16:09 oising

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 avatar Sep 13 '21 23:09 jessey-git

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 avatar Oct 07 '21 14:10 zadjii-msft

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 avatar Oct 07 '21 18:10 oising

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 avatar Oct 14 '21 15:10 oising

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 avatar Oct 14 '21 15:10 oising

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 avatar Oct 14 '21 18:10 jessey-git

Version 1.12.2931.0 remains broken on Win10 for me.

jessey-git avatar Oct 22 '21 19:10 jessey-git

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 avatar Nov 05 '21 17:11 kstange

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

image

oising avatar Nov 18 '21 19:11 oising

1.12.2931.0 still broken

jessey-git avatar Dec 15 '21 02:12 jessey-git

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 avatar Feb 26 '22 16:02 Diu

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 avatar Mar 01 '22 17:03 zadjii-msft

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 avatar Mar 14 '22 16:03 guhetier

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 avatar Apr 08 '22 11:04 zadjii-msft

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 avatar Apr 08 '22 15:04 oising

Linking some threads:

  • #11214
  • #11334
  • #12805
    • possibly also #14530
  • #13840
  • #14512

zadjii-msft avatar Oct 26 '22 21:10 zadjii-msft

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 avatar Aug 15 '23 13:08 zadjii-msft

@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 avatar Aug 15 '23 17:08 oising

Closed as fixed.

oising avatar Aug 15 '23 17:08 oising