mangled output after update to 1.18.10301.0

[jeremyd2019]

Windows Terminal version

1.18.10301.0

Windows build number

10.0.19045.3930

Other Software

msys2 (msys2-runtime-3.3-3.3.6-6)

Steps to reproduce

start msys2 shell, run pacman -Syuu

Expected Behavior

In 1.18.3181.0:

Actual Behavior

In 1.18.10301.0:

[jeremyd2019]

Looks like 1.19.10302.0 is not having this issue (though I notice the font looks different now, probably a 'feature').

I'm also not seeing this with 1.18.10301.0 on another machine with msys2-runtime 3.4.10-4.

An interesting point about the machine that shows this bug is that it is 32-bit Windows 10 (that is, x86). That's also why I'm using msys2-runtime 3.3 (the last version that supported 32-bit Windows)

[DHowett]

Interesting! If you select/copy/paste the empty regions, are they truly empty? I'm wondering if the issue is somewhere in the text buffer or in the renderer. The text being missing from the copy would exonerate the rendering engine.

(though I notice the font looks different now, probably a 'feature').

You do not need to use pejorative quotation marks here. 1.19 replaces our inefficient and often entirely incorrect rendering engine with the new one (which has been in various stages of rollout over the past six months!) by default. It can be turned back off -- but if you have a problem with the font rendering, I'd encourage you to file an issue so we can talk about it.

[jeremyd2019]

Copy/paste from 1.18.10301.0:

resolving dependencies...
looking for conflicting packages...

Packages (15) mingw-w64-clang-i686-crt-git-11.0.0.r631.ga4c0c1d00-1
              mingw-w64-clang-i686-headers-git-11.0.0.r631.ga4c0c1d00-1
              mingw-w64-clang-i686-libgit2-1.7.2-1
              mingw-w64-clang-i686-libmangle-git-11.0.0.r631.ga4c0c1d00-1
              mingw-w64-clang-i686-libwinpthread-git-11.0.0.r631.ga4c0c1d00-1
              mingw-w64-clang-i686-tools-git-11.0.0.r631.ga4c0c1d00-1
              mingw-w64-clang-i686-winpthreads-git-11.0.0.r631.ga4c0c1d00-1
              mingw-w64-clang-i686-winstorecompat-git-11.0.0.r631.ga4c0c1d00-1
              mingw-w64-i686-crt-git-11.0.0.r631.ga4c0c1d00-1
              mingw-w64-i686-headers-git-11.0.0.r631.ga4c0c1d00-1
              mingw-w64-i686-libmangle-git-11.0.0.r631.ga4c0c1d00-1
              mingw-w64-i686-libwinpthread-git-11.0.0.r631.ga4c0c1d00-1
              mingw-w64-i686-tools-git-11.0.0.r631.ga4c0c1d00-1
              mingw-w64-i686-winpthreads-git-11.0.0.r631.ga4c0c1d00-1
              mingw-w64-i686-winstorecompat-git-11.0.0.r631.ga4c0c1d00-1

Total Download Size:    19.25 MiB
Total Installed Size:  307.37 MiB
Net Upgrade Size:       21.88 MiB

:: Proceed with installation? [Y/n]

No mangled output, so it seems to be the renderer? Even more interesting, selecting the text causes it to be redrawn correctly.

You do not need to use pejorative quotation marks here.

Sorry. I only installed 1.19 to see if it had the issue too (it did not), and was just kind of startled that it looked different. That was only my general aversion to change making itself known 😁

[DHowett]

WHAT! I never expected it to actually end up being the renderer (!)

@lhecker I know this is just DxEngine, but... have you ever seen this?

general aversion to change

Totally fair, thank you 🙂

(Sorry for the trigger finger on calling you out about it, too!)

[jeremyd2019]

Interesting that whatever is going on only seems to happen in 1.18.10301.0, and not in 1.18.3181.0 or 1.19.10302.0.

[lhecker]

I can't reproduce this issue on my x64 PC with ~about the same software revisions. I'll set up a x86 VM next week. Can you try this for me please in the meantime?

Save this as passthrough.hlsl (or similar) somewhere:

Texture2D shaderTexture;
SamplerState samplerState;

cbuffer PixelShaderSettings {
    float time;
    float scale;
    float2 resolution;
    float4 background;
};

float4 main(float4 pos : SV_POSITION, float2 tex : TEXCOORD) : SV_TARGET
{
    return shaderTexture.Sample(samplerState, tex) * clamp(time, 0.9, 1);
}

Open the settings.json file in Windows Terminal by pressing Ctrl+Shift+(comma) and add this to the .profile.defaults object:

"experimental.pixelShaderPath": "C:\\foo\\bar\\passthrough.hlsl"

Can you then check if the issue still occurs?

What the above does is to cause the terminal to re-render the contents continuously without stopping. If the issue still occurs, then I probably have a bug in the scrolling code, otherwise (if it stops occurring) I have a bug in my display invalidation code.

[jeremyd2019]

OK, tried back and forth taking the hlsl reference in and out of settings to be sure... With hlsl in settings, text draws correctly. Without it the text is mangled again.

I wouldn't necessarily be surprised if it had something to do with the ancient drivers/hardware either, which could make it especially hard for you to reproduce. I would think that it only happens in that one version (which seemed to be a pretty small hotfix release) should make it easier to narrow down.

[lhecker]

I'll try to reproduce it in a x86 VM just to be sure. If it doesn't reproduce I'll add a setting to disable "partial invalidation" (aka IDXGISwapChain1::Present1; which is what is causing your issue).

In the meantime I can only suggest disabling AtlasEngine in the Rendering settings. The old text renderer will go away in the next release though, so if possible, please only disable it on that one machine. 🙂

[jeremyd2019]

OK, I figured this was the case but went ahead and tested to be sure: I just opened cmd and ran dir c:\windows\system32 and saw messed up drawing. It seems to be less reproducible than my pacman example (not every attempt has drawing issues), but doesn't require any particular 3rd party software (such as the unsupported 32-bit msys2).

[lhecker]

We figured out what's happening. Your build is the first one that uses MSVC 19.38 (aka Visual Studio 17.8) and that one miscompiles some of our code on x86. We fixed the issue in #16742 and are planning to backport it to the older builds in the near term.

[jeremyd2019]

Sweet, a compiler bug?!? Not what I would have expected. I'll keep an eye out for an update from the store (I try to keep on what the store offers me, rather than being proactive about getting updates from github for instance)

[jeremyd2019]

I got the update to 1.19.10573.0 via the store today, and I don't see this issue anymore, with useAtlasEngine true or false (I'm pretty sure I didn't see the issue with the atlas engine enabled when I tried a prior 1.19 build, but I didn't know that it was the engine that changed just that the font looked different, so I didn't try turning it off).