Transparent background doesn't become transparent foreground when rendered in reverse video

[PhMajerus]

The new Preview 1.2.2022.0 seems to fix all the VT colors issues I observed before, except one last case:

When the background color is the default (49), it is correctly kept transparent, but if the foreground color is transparent, which is possible when the background is 49 and then the colors are reversed using 7, it is rendered as black instead of transparent.

echo -e "\e[31m\u2580\e[7m\u2580\e[m"
echo -e "\e[31m\u2590\e[7m\u25A0\e[27m\u258C\e[m"

In both cases, there should be no black square, the acrylic transparency should show through instead.

[DHowett]

Oh yeah, we need to do an inverse alpha mask with the shaped text. It's expensive and something we chose to not to.

[PhMajerus]

Could we get that behavior through an optional flag ?
I understand your performance goal, but for some ANSI-art effects, the only solution is to use an existing character reversed, such as for the 3-cells square above. Would be nice to be able to turn it on for specific profiles.

[DHowett]

Meh, I'd be inclined to implement it and not make it configurable -- it's more expensive on the engineering side than it is on the runtime side, I expect. 😄

[PhMajerus]

@DHowett 👍 Great, can't wait to see it implemented then 😁

Especially since you can use it only when you have that specific attributes combination, the current code can be used for faster rendering in every other case, and that combination would definitely look more correct taking advantage of the acrylic effect.

[DHowett]

Notes:

We can't use a geometry mask based on the glyph run, because we want to fill outside of the geometry and not touch inside the geometry[1].

We may need to use an alpha bitmap (1bpp black and white, converted to an alpha mask) like we did in Islandwood's CGImage and push a layer whose opacity bitmap is this guy.

[1]: Nevermind, I just saw ID2D1Geometry::CombineWithGeometry; perhaps we can just create a Rectangle geometry, combine EXCLUDE the glyph geometries, and fill that...

[DHowett]

Hey @PhMajerus,

[PhMajerus]

That was fast, thank you @DHowett \(^_^)/

[DHowett]

So, it's still got some issues. I want to make sure it works on non-native-scale displays, and follows the antialiasing mode set for the font, and uh it completely breaks hinting (because we're just getting the text geometry and not letting the rasterizer at it)

[thanhph111]

@DHowett Sorry to bother you again and mess up this issue.

How can you do that? I try to use Write-Host to write the same but it didn't work. I spent all night to read #6810 as you mention but also have no clue. I did:

• Run on Windows Terminal 1.2.2022.0
• Run with PSReadline 2.0.3
• Run on PowerShell Core 7.0.3

The test below I use black as the same as the background color (#000000) and the white color as the same as the foreground color (#FFFFFF) but it seems that abc is not transparent at all. I hope if text works, glyph should work also.

[PhMajerus]

@thanhph111 Write-Host arguments were designed for the Console API, they do not translate to the VT sequences we're using here.
You need to generate your VT control sequences manually, for example :
PowerShell 7 and later:
Write-Output "`e[97;7m Transparent on white `e[m"
Windows PowerShell:
Write-Output "$([char]27)[97;7m Transparent on white $([char]27)[m"
Or you can use some other cmdlet or component that can generate strings with proper escape sequences.

Of course these will show black on white in the current 1.2 preview build of Windows Terminal, which is the topic of this issue thread.

VT and ANSI-art in Windows PowerShell 5.1.19041.1 within Windows Terminal 1.2.2022.0.

[PhMajerus]

So, it's still got some issues. I want to make sure it works on non-native-scale displays, and follows the antialiasing mode set for the font, and uh it completely breaks hinting (because we're just getting the text geometry and not letting the rasterizer at it)

I didn't go see your code, but since there are only two colors, and in this scenario one of them is transparent, wouldn't bit-fiddling from the positive rendering be enough (and fast if you can run that in a GPU shader) ?

It seems like your final pixels can be taken from the positive rendered cell: the positive rendered alpha reversed (A2 = 255-A1) and RGB fixed to the non transparent color for the whole cell. The alpha should be all that is needed to recover the exact opposite of the shape and RGB values of transparent pixels colors won't matter, so fixing the color for all pixels except for their alpha values should be faster and more reliable than trying to reverse the RGB values.

[DHowett]

So for efficiency's sake, I'm trying to avoid capturing the positive render as an image and then inverting it before it goes out.

There's a world where we could easily render the text in black with grayscale AA on white to a temporary bitmap target then draw through that as an alpha mask (ala CGCreateMaskImage from WinObjC above^), but going there would slay performance and introduce a lot of buffer/target churn.

We're also not set up to apply pixel shaders generically, and for doing it off the GPU I'm not sure we can easily grab the backing buffer and alpha-invert just the region we care about without jumping through rather a couple hoops, either.

For the best bang-for-your-buck tradeoff I'm most comfortable with the negative geometry solution... even if it does break hinting.

[jales]

@DHowett Are there any plans to merge your changes in a future version?

[DHowett]

@jales not as yet; they are insufficient right now

[carpet92]

@DHowett

There is info about fix this bug in 1.15.18620 changelog:

We no longer suppress black blackground or gray foreground for PowerShell (#13352)

• We have chosen to remove this workaround as newer versions of PowerShell's PSReadline component contain a fix for the issue.
• This was a compatibility band-aid that was impacting the capabilities of great projects such as Oh My Posh.
• ❗ If you see unexpected black backgrounds appearing behind text while typing a command in PowerShell, make sure your PSReadline version is up to date. You can update your version of PSReadline by running the command, Update-Module PSReadline.

I have installed PSReadline 2.2.6 by Install-Module -Name PSReadline -Force for PS 7.2.5. But for me the issue is still reproduces on the latest 1.15.18620.

Related discussion: JanDeDobbeleer/oh-my-posh#2555

How to fix the issue as it done in this comment?: #7014 (comment)

[zeratax]

I can still reproduce this as well on 1.17.1023

[DHowett]

Thanks for the report! That would be because it has not yet been fixed.

[FrostKiwi]

Want to confirm it being broken on my machine as well with ver 1.17.11461.0, as reported in #15491 and #15491

[DHowett]

Thanks for the report! Yes, this is not machine-specific and requires explicit work in the renderer. We recently put a lot of effort into the new rendering engine, and we think that it should be possible to do this properly.

[silkfire]

What's the status on this? Still present in 1.18.3181.0

[zadjii-msft]

Yep. We'll make sure to update this thread when there are updates. If someone's interested in trying to fix this themselves, we'd be more than happy to point in the right direction!