Display corruption after resizing on some Intel cards

[realparadyne]

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.

Expected Behavior

Resotring the window from fullscreen should restore the display fully.

Actual Behavior

Resotring the window from fullscreen can leave visual corruption.

[lhecker]

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

[realparadyne]

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]

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]

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.

[lhecker]

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.

[tusharsnx]

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

[pujfei]

@tusharsnx that's true!

[tusharsnx]

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.

[zadjii-msft]

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

[lhecker]

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

[tusharsnx]

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