Terminal: 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. :smile:

[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.

[thanhph111]

I understand there're more priority to get done but I just want to add another case what need this feature more frequently.
As you can see in the image below, I use posh-git to draw prompt with segment forward symbol expected to be colored like background. However, as useAcrylic is set, the symbol is revealed with default black.

Hope to see this one added in the future.

[DHowett]

@thanhph111

Unless you're using reverse video and your powerline prompt is actually using 49 as the background (not 40), "...LAPTOP" is supposed to be white on black and the problem you're seeing is definitely not the one reported in this bug.

Can you confirm whether your prompt is officially using 7;49;34 (blue on default, reverse) or 44;30 (black on blue)?

[thanhph111]

@DHowett
I actually get the color from the console and use the Write-Prompt (code below) to draw it out. So I think issue is from the terminal.
Maybe I miss something, please correct me.

Write-Prompt:

function Write-Prompt($Object, $ForegroundColor = $null, $BackgroundColor = $null) {
    $s = $global:GitPromptSettings

    if ($BackgroundColor -is [string]) {
        $BackgroundColor = [ConsoleColor]$BackgroundColor
    }
    if ($ForegroundColor -is [string]) {
        $ForegroundColor = [ConsoleColor]$ForegroundColor
    }

    $writeHostParams = @{
        Object = $Object;
        NoNewLine = $true;
    }
    if (($BackgroundColor -ge 0) -and ($BackgroundColor -le 15)) {
        $writeHostParams.BackgroundColor = $BackgroundColor
    }
    if (($ForegroundColor -ge 0) -and ($ForegroundColor -le 15)) {
        $writeHostParams.ForegroundColor = $ForegroundColor
    }
    Write-Host @writeHostParams
}

[DHowett]

In that case, you're seeing the results of the color compatibility work done in #6810 and your issue is not that the arrow is black but that the text to the left of it is _not_ white-on-black.

[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:

• [x] Run on Windows Terminal 1.2.2022.0
• [x] Run with PSReadline 2.0.3
• [x] 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.