Transparent background doesn&#39;t become transparent foreground when rendered in reverse video #9746

@DHowett commented on GitHub (Jul 22, 2020):

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

@DHowett commented on GitHub (Jul 22, 2020): 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:

claunia commented

@PhMajerus commented on GitHub (Jul 22, 2020):

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

@PhMajerus commented on GitHub (Jul 22, 2020): @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.

claunia commented

@DHowett commented on GitHub (Jul 23, 2020):

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 commented on GitHub (Jul 23, 2020): 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](https://github.com/microsoft/WinObjC/blob/ea3f7983803fa02309f974ff878b6c9ecc72c7c4/Frameworks/CoreGraphics/CGImage.mm#L805-L864) and push a layer whose opacity bitmap is this guy. [1]: Nevermind, I just saw [ID2D1Geometry::CombineWithGeometry](https://docs.microsoft.com/en-us/windows/win32/api/d2d1/nf-d2d1-id2d1geometry-combinewithgeometry(id2d1geometry_d2d1_combine_mode_constd2d1_matrix_3x2_f__id2d1simplifiedgeometrysink)?redirectedfrom=MSDN); perhaps we can just create a Rectangle geometry, combine EXCLUDE the glyph geometries, and fill that...

claunia commented

@thanhph111 commented on GitHub (Jul 23, 2020):

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.

@thanhph111 commented on GitHub (Jul 23, 2020): 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](https://github.com/dahlbyk/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. ![image](https://user-images.githubusercontent.com/60842560/88313264-7a7e0600-cd3d-11ea-8b0f-e53ae53cb6bc.png) Hope to see this one added in the future.

claunia commented

@DHowett commented on GitHub (Jul 23, 2020):

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

@DHowett commented on GitHub (Jul 23, 2020): @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)?

claunia commented

@thanhph111 commented on GitHub (Jul 23, 2020):

@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
}

@thanhph111 commented on GitHub (Jul 23, 2020): @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. ![image](https://user-images.githubusercontent.com/60842560/88321533-88398880-cd49-11ea-8f48-6c65683f4d1a.png) `Write-Prompt`: ``` shell 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 } ```

claunia commented

@DHowett commented on GitHub (Jul 23, 2020):

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 commented on GitHub (Jul 23, 2020): 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.

claunia commented

@DHowett commented on GitHub (Jul 23, 2020):

Hey @PhMajerus,

@DHowett commented on GitHub (Jul 23, 2020): Hey @PhMajerus, ![image](https://user-images.githubusercontent.com/189190/88325582-1d9d3400-ccda-11ea-9951-7bbeedad11b6.png) ![image](https://user-images.githubusercontent.com/189190/88325933-61903900-ccda-11ea-9991-88f2ae5533f5.png)

claunia commented

2026-01-31 02:02:53 +00:00

@PhMajerus commented on GitHub (Jul 23, 2020):

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

@PhMajerus commented on GitHub (Jul 23, 2020): That was fast, thank you @DHowett \\(^_^)/

claunia commented

@DHowett commented on GitHub (Jul 24, 2020):

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)

@DHowett commented on GitHub (Jul 24, 2020): 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)

claunia commented

2026-01-31 02:02:53 +00:00

@thanhph111 commented on GitHub (Jul 24, 2020):

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

@thanhph111 commented on GitHub (Jul 24, 2020): @DHowett Sorry to bother you again and mess up this issue. > ![image](https://user-images.githubusercontent.com/189190/88325582-1d9d3400-ccda-11ea-9951-7bbeedad11b6.png) > ![image](https://user-images.githubusercontent.com/189190/88325933-61903900-ccda-11ea-9991-88f2ae5533f5.png) 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](https://github.com/microsoft/terminal/issues/7014#issuecomment-663117947) should work also. ![image](https://user-images.githubusercontent.com/60842560/88378704-b8297000-cdcb-11ea-9cbc-e5406324b363.png)

claunia commented

2026-01-31 02:02:53 +00:00

@PhMajerus commented on GitHub (Jul 24, 2020):

@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 commented on GitHub (Jul 24, 2020): @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. ![image](https://user-images.githubusercontent.com/25664275/88383029-fb72e700-cda9-11ea-9378-8c1731171055.png) VT and ANSI-art in Windows PowerShell 5.1.19041.1 within Windows Terminal 1.2.2022.0.

claunia commented

@PhMajerus commented on GitHub (Jul 24, 2020):

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.

@PhMajerus commented on GitHub (Jul 24, 2020): > 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.

claunia commented

@DHowett commented on GitHub (Jul 24, 2020):

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.

@DHowett commented on GitHub (Jul 24, 2020): 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.

claunia commented

@jales commented on GitHub (Dec 18, 2020):

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

@jales commented on GitHub (Dec 18, 2020): @DHowett Are there any plans to merge your changes in a future version?

claunia commented

@DHowett commented on GitHub (Dec 18, 2020):

@jales not as yet; they are insufficient right now

@DHowett commented on GitHub (Dec 18, 2020): @jales not as yet; they are insufficient right now

claunia commented

@carpet92 commented on GitHub (Jul 21, 2022):

@DHowett

There is info about fix this bug in 1.15.18620 changelog:

We no longer suppress black blackground or gray foreground for PowerShell (https://github.com/microsoft/terminal/pull/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: https://github.com/JanDeDobbeleer/oh-my-posh/discussions/2555

How to fix the issue as it done in this comment?: https://github.com/microsoft/terminal/issues/7014#issuecomment-663464319

@carpet92 commented on GitHub (Jul 21, 2022): @DHowett There is info about fix this bug in [1.15.18620](https://github.com/microsoft/terminal/releases/tag/v1.15.1862.0) changelog: > We no longer suppress black blackground or gray foreground for PowerShell (https://github.com/microsoft/terminal/pull/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](https://ohmyposh.dev/). - ❗ 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: https://github.com/JanDeDobbeleer/oh-my-posh/discussions/2555 How to fix the issue as it done in this comment?: https://github.com/microsoft/terminal/issues/7014#issuecomment-663464319

claunia commented

@zeratax commented on GitHub (Mar 14, 2023):

I can still reproduce this as well on 1.17.1023

@zeratax commented on GitHub (Mar 14, 2023): I can still reproduce this as well on 1.17.1023

claunia commented

@DHowett commented on GitHub (Mar 14, 2023):

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

@DHowett commented on GitHub (Mar 14, 2023): Thanks for the report! That would be because it has not yet been fixed.

claunia commented

@FrostKiwi commented on GitHub (Jul 14, 2023):

Want to confirm it being broken on my machine as well with ver 1.17.11461.0, as reported in https://github.com/microsoft/terminal/issues/15491 and https://github.com/microsoft/terminal/issues/15491

@FrostKiwi commented on GitHub (Jul 14, 2023): Want to confirm it being broken on my machine as well with `ver 1.17.11461.0`, as reported in https://github.com/microsoft/terminal/issues/15491 and https://github.com/microsoft/terminal/issues/15491 ![image](https://github.com/microsoft/terminal/assets/60887273/f9a474a7-4226-4205-8d5d-741adc0cd798)

claunia commented

@DHowett commented on GitHub (Jul 14, 2023):

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.

@DHowett commented on GitHub (Jul 14, 2023): 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.

claunia commented