terminal icon indicating copy to clipboard operation
terminal copied to clipboard

Display corruption after resizing on some Intel cards

Open realparadyne opened this issue 2 years ago • 9 comments

Windows Terminal version

1.17.1023

Windows build number

22621.1265

Other Software

No response

Steps to reproduce

On my laptop, when it is set to use only the internal display or duplicate the display (so not extend mode) then when the terminal exits fullscreen mode there is corruption to the right and below the now restored window. Moving the window corrects the corruption but not all at once. The corrupted area can be the desktop background or another window and it appears just as a black area. I could not screensclip the corrupted display as that immediately corrects the corruption before the screenshot can be taken, so I've had to resort to photos of the screen! I could not reproduce this when using just an external display, or extend mode, or on my desktop PC with a 4k display. This laptop is a 2880x1800 display, and a typical i7-1260P with Intel integrated graphics so a very common configuration.

IMG_20230217_155946

IMG_20230217_161820

Expected Behavior

Resotring the window from fullscreen should restore the display fully.

Actual Behavior

Resotring the window from fullscreen can leave visual corruption.

realparadyne avatar Feb 17 '23 16:02 realparadyne

Since the i7-1260P is a very new CPU with an equally new GPU, I suspect that this is a driver issue. Unfortunately, I don't have a comparable Intel system at hand with which I could test this either. Is there some way you could check if you have the most recent Intel Xe drivers installed?

If not, as an experiment, you could try installing them from here? https://www.intel.com/content/www/us/en/download/726609/intel-arc-iris-xe-graphics-whql-windows.html

lhecker avatar Feb 20 '23 14:02 lhecker

I updated the drivers but there was no change. I did some further tests:

  1. Screen refresh rate 60 or 90Hz makes no difference.
  2. Original console host does not have this behaviour.
  3. Other applications with a full screen mode (Visual Studio Zen mode) do not have the issue.
  4. Repeatedly entering and exiting full screen display the corruption 100% of the time but it can vary slightly as to what exact area is left black.

I think it's something specific to the way Terminal handles full screen mode transitions and is either rendering some background again after exiting full screen mode or somehow not triggering Windows to repaint the uncovered areas. I did also wonder if there was some interaction with Panel Self Refresh but I can't find a way to turn it off (if it even has it on thie OLED panel).

realparadyne avatar Feb 21 '23 11:02 realparadyne

I discovered it is the AtlasEngine renderer specifically. I'm wondering if there is a race when fullscreen mode is exited. It 'looks' as though the window is moved, then resized, and then a final render occurs at the larger size because the black area is always to the right and below the window.

realparadyne avatar Feb 21 '23 11:02 realparadyne

Ok, so it seems it is the 'resize' of the window that's the issue, when the window is made smaller the renderer (which appears to be on a background thread?) can render at the previous size. I was able to show this by grabbing the bottom right corner of the window and rapidly shrinking and expanding the window. I was also able to replicate it that way on my desktop system. It looks like a race condition between the new windows size and a render operation 'Present()' that is already started, or something like that.

realparadyne avatar Feb 21 '23 12:02 realparadyne

I found a way to reproduce this on my Nvidia GPU by repeatedly pressing F11 when connected to my TV. Coincidentally it's the other of the 2 GPU manufacturers who seems to have problems with >1 active multiplane overlay (MPO) while using dirty rectangles during flip presentation. I'll try and see if applying DWMWA_CLOAK to the terminal window during fullscreen transition can avoid the issue. There's also a chance that we can avoid this by preventing WinUI (the other MPO) from drawing during the transition.

lhecker avatar Feb 25 '23 13:02 lhecker

In my brief testing, it looks like this is a window size dependent issue. It only occurs if the window size is sufficiently big.

https://github.com/microsoft/terminal/assets/55626797/63fc2e2d-b44a-4ba1-8ccd-bca6a157584e

tusharsnx avatar Apr 25 '24 14:04 tusharsnx

@tusharsnx that's true!

pujfei avatar May 08 '24 16:05 pujfei

If I set the opacity to anything but 100%, the issue disappears!

@lhecker If I force useAlpha to be true, it seems to solve the issue but it also takes away "Independent Flip".

https://github.com/microsoft/terminal/blob/49e4eea60f737b46b8aeda505f4693df8a9d44a6/src/renderer/atlas/AtlasEngine.api.cpp#L532

@pujfei As a workaround, I think you can set window opacity to 99%, which should force no Independent-Flip.

Screenshot 2024-05-09 150611

tusharsnx avatar May 09 '24 09:05 tusharsnx

@lhecker has a thread out with the DWM folks currently for this thread - they suspect it may be a DWM issue. They may need some specific traces to help investigate, we'll reach out when we get more info. (including an internal work item to link this to).

zadjii-msft avatar May 09 '24 11:05 zadjii-msft

Sorry for the delay. 😟 I've filed this internally as MSFT:51009903 now.

lhecker avatar May 17 '24 12:05 lhecker

As of Windows build 26100.1000 (Release preview), I can't repro this at the moment. Hope it's fixed internally.

Windows Terminal: 1.20.11781.0

tusharsnx avatar Jul 05 '24 06:07 tusharsnx