Repository: microsoft/terminal (language: cpp)

Issue:
Graphical glitches when using hardware rendering
### Windows Terminal version

1.17.1023

### Windows build number

22H2 22622.608

### Other Software

_No response_

### Steps to reproduce

1. Open Terminal stable or preview
2. Open Powershell or WSL2 tab
3. Start typing and notice the odd rendering
4. Switch to software rendering
5. Return to terminal tab
6. Start typing and notice no rendering glitches

### Expected Behavior

Expect that the rendering is the same as software mode where there are no glitches.

### Actual Behavior

Glitches appear where the cursor appears to lag or doesn't render the character or multiple characters until another key is pressed.

See video for example:

https://user-images.githubusercontent.com/76320/232841647-65a4e126-b05a-47ab-98d4-2e5069cbfb6d.mp4




Discussion / hints:
I've tried changing the font and colour scheme but they all produce the same result. The only way to stop the glitch is software rendering.
You say
> Open Terminal stable or preview

but those two use entirely different text renderers by default. Do you have "AtlasEngine" in the "Rendering" settings enabled in Windows Terminal stable (1.16.10262.0)? If so, could you disable that setting? If the issue still happens then, then it's possible your hardware is faulty, because the two text renderers were written independent of each other and have an entirely different architecture.
I did have AtlasEngine enabled in both. I've now disabled AtlasEngine in Windows Terminal stable and I'll see if the problem occurs during work today. Current settings in Windows Terminal stable:
![image](https://user-images.githubusercontent.com/76320/232990792-a74a85eb-c61d-402b-b4ad-37448a82065a.png)

The issue only started happening about a week ago and I'm wondering whether it coincided with a graphics card update (NVidia Geforce 2070 Super). I updated the drivers again today with the latest release and can confirm the issue still happens on Windows Terminal preview with AtlasEngine on or off and software rendering off.
After a full work day using Windows Terminal stable with AtlasEngine off I can say that I haven't seen the graphical glitch. I'm now trying with AtlasEngine on and after 10 minutes the glitch hasn't appeared.

Using Windows Terminal preview with Atlas Engine at first it all seems good. Then the glitch appears after a short time using the terminal, maybe a minute. Once the glitch appears it stays in that terminal and affects all splits.
Hmm... the version of AtlasEngine in stable and preview is identical. I wonder if it's maybe a compiler bug? (It wouldn't be our first!) Or some other form of race condition? 1.18 will release with an entirely new version of AtlasEngine, so I'm cautiously optimistic that the issue will be resolved as a side effect.
I'll tag this one up as "We think it's fixed in 1.18, and we'll come back to validate"
As of version 1.18.1421.0, I'm encountering similar glitching when AtlasEngine is enabled. 

Block cursor moves as I am typing, but letters are covered entirely by the block. Typing a command, ie `dig microsoft.com` does not show the output (blank lines) but moves cursor down.  Switching windows (Alt Tab) makes all the text appear (both typed and output).

Disabling AtlasEngine resolves the issue.

- WSL2 terminal for Ubuntu
- "Ubuntu-ColorScheme" 
- "MesloLGS NF" font
- ZSH with Oh My ZSH + powerlevel10K
- Font size 10

The rest defaults. Intel Arc A370 GPU and Iris Xe (31.0.101.4369, beta-driver opt-out).
> "MesloLGS NF" font

This is most definitely what @lhecker just fixed in #15403. I think we'll have that our for servicing sometime in the next 1-2 weeks
It 100% is. I'm sorry for causing the issue - We only noticed it mere hours before publishing 1.18. If you can and don't mind, it'd be great if you could use an alternative font just for a week, because it would help us find other potential bugs you might encounter. I personally for instance like using [Delugia](https://github.com/adam7/delugia-code). Otherwise I hope we'll be able to ship a fix soon!
Thanks @lhecker - with Delugia and AtlasEngine enabled again, it seems fine. Much appreciated!
If you need any more data points, with AtlasEngine and ClearType on I experience the same glitches, but changing to "Aliased" text everything works fine. (I don't know how relevant that is)

I'm using Terminal Preview v1.18.1421.0, running `zsh` on Ubuntu 22.04.2 LTS with CaskaydiaCove NF Mono font and the Tango Dark colour scheme.

Also, changing the alias mode while the Ubuntu terminal is open results in the error:
> Renderer encountered an unexpected error: -2005270527

> If you need any more data points, with AtlasEngine and ClearType on I experience the same glitches, but changing to "Aliased" text everything works fine. (I don't know how relevant that is)

Yeah, that makes sense. The problematic fonts pretty much only clip out of the viewport by 1 pixel, which then triggers #15403. Aliased text is probably just 1px less tall.

Over at #14082 I posted a custom Windows Terminal Preview version yesterday that integrates 3 AtlasEngine bug fixes. You can download it here: [blob.hecker.io/sharex/Microsoft.WindowsTerminalPreview_1.18.1443.0_8wekyb3d8bbwe.msixbundle](https://blob.hecker.io/sharex/Microsoft.WindowsTerminalPreview_1.18.1443.0_8wekyb3d8bbwe.msixbundle)
I'm using my own personal domain because I don't want to expose my internal work addresses. However, the file is properly cryptographically signed by Microsoft. You can try it out if you'd like! I'm pretty confident that it fixes the MesloLGM NF bug and similar.
Awesome yes, can confirm that fixed it! 👍

Thanks for the info about CaskaydiaCove having issues. Will try out the other font recommendations.
I'm also having an issue when using hardware rendering, all text will either render black or as lines about 35% of the time. It'll all render as vertical pipe characters, then sometimes a reflow/refresh will fix it, or typing CLEAR in Ubuntu. NVidia latest drivers, 3080Ti, Win10, happy to help trouble shoot. It stops when disabling hardware rendering.
@jx Does the issue reproduce on Windows Terminal Preview v1.18.1462.0?
If it does, could you please try to describe any steps I would have to take to reproduce it on my machine if I were to start from a clean state? I mean things like your font family, font size, what shell you use, an application or some text string that reproduces the issue, etc. Anything you think is necessary to reproduce it basically. That way I could run it under a debugger to see what’s going on. 🙂
@lhecker I rolled back my video drivers and can't reproduce this at all. Sorry it took me three weeks! But I can't repro it at all now, so I think there was a problem with the nVidia drivers.

I had to roll them back for another reason: one of my monitors kept cutting out and after I swapped the cable and verified nothing was loose, I rolled back the gfx driver. All the issues went away. I'm on 532.03 GR, not Studio drivers. What else would you like me to test?
Wait wait wait…
You _also_ have this issue where your monitor signal is cutting out? I started getting this issue suddenly last week and it weakly correlates with a Nvidia graphics driver update. That’s interesting! I guess I’ll also have to try and downgrade it.

If you’d like to test anything, please let me know if you find any unusual rendering issues in Windows Terminal Preview 1.18, for instance anything like what OP reported.
Yes! It all started around the same time but the cutting out of the display was rare and just got worse over a couple of days. Once I rolled back all was golden. Everything works on this version I mentioned including preview. I only run preview builds. 
Hokay so it sounds like the issue @jx was having was related to some nvidia drivers.  Otherwise, we're pretty sure this should be fixed on the _latest_ 1.18 build, https://github.com/microsoft/terminal/releases/tag/v1.18.1462.0. @tanc you want to give that build a try to confirm/?
I'm currently on 1.18.1462.0 presently, no issues here. Hopefully the same is true for @tanc !
Unfortunately on `1.18.1462.0` I'm still seeing graphical glitches:

https://github.com/microsoft/terminal/assets/76320/6377dec6-86de-4924-88fa-a57c9a50b35a

Whilst on the stable version I have no issues.
@tanc Can you try this for me? Save this as `passthrough.hlsl` (or similar):
```hlsl
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);
}
```

Then open your `settings.json` and add that file as your shader like so:
```json
{
    "profiles":
    {
        "defaults": {
            "experimental.pixelShaderPath": "C:\\foo\\bar\\passthrough.hlsl"
        }
    }
}
```

Afterwards restart Windows Terminal (just to be sure). Does it still reproduce then?
Additionally, do you think you could produce some instructions for me how I can reproduce your WSL setup and shell exactly?
I've just left for holiday for three weeks so I can't test as this only happens on my desktop machine. When I get back I'll test and try to put together as much as I can as repro steps
@lhecker I've just got back and I've added the `passthrough.hlsl` to my `settings.json` and can confirm the glitch no longer presents itself. Commenting out the `experimental.pixelShaderPath` line and saving `settings.json` re-activates the display glitch.

Fix patch:
diff --git a/src/renderer/atlas/AtlasEngine.cpp b/src/renderer/atlas/AtlasEngine.cpp
index 874a4c38900..3d5ffdb8ed0 100644
--- a/src/renderer/atlas/AtlasEngine.cpp
+++ b/src/renderer/atlas/AtlasEngine.cpp
@@ -251,6 +251,16 @@ try
 {
     _flushBufferLine();
 
+    // PaintCursor() is only called when the cursor is visible, but we need to invalidate the cursor area
+    // even if it isn't. Otherwise a transition from a visible to an invisible cursor wouldn't be rendered.
+    if (const auto r = _api.invalidatedCursorArea; r.non_empty())
+    {
+        _p.dirtyRectInPx.left = std::min(_p.dirtyRectInPx.left, r.left * _p.s->font->cellSize.x);
+        _p.dirtyRectInPx.top = std::min(_p.dirtyRectInPx.top, r.top * _p.s->font->cellSize.y);
+        _p.dirtyRectInPx.right = std::max(_p.dirtyRectInPx.right, r.right * _p.s->font->cellSize.x);
+        _p.dirtyRectInPx.bottom = std::max(_p.dirtyRectInPx.bottom, r.bottom * _p.s->font->cellSize.y);
+    }
+
     _api.invalidatedCursorArea = invalidatedAreaNone;
     _api.invalidatedRows = invalidatedRowsNone;
     _api.scrollOffset = 0;
@@ -423,15 +433,6 @@ try
         }
     }
 
-    // Clear the previous cursor
-    if (const auto r = _api.invalidatedCursorArea; r.non_empty())
-    {
-        _p.dirtyRectInPx.left = std::min(_p.dirtyRectInPx.left, r.left * _p.s->font->cellSize.x);
-        _p.dirtyRectInPx.top = std::min(_p.dirtyRectInPx.top, r.top * _p.s->font->cellSize.y);
-        _p.dirtyRectInPx.right = std::max(_p.dirtyRectInPx.right, r.right * _p.s->font->cellSize.x);
-        _p.dirtyRectInPx.bottom = std::max(_p.dirtyRectInPx.bottom, r.bottom * _p.s->font->cellSize.y);
-    }
-
     if (options.isOn)
     {
         const auto cursorWidth = 1 + (options.fIsDoubleWidth & (options.cursorType != CursorType::VerticalBar));


Test patch: