Handling transparent BG color when used as FG

[Eugeny]

Nano displays its shortcuts with FG/BG colors reversed:

However, when theme BG is transparent, following happens:

The solution could be to have a separate flag that will render characters with no background as if background were transparent instead of theme.backgroundColor, but will still use the actual color for inverted elements.

[chabou]

I think it could work if alpha is forced to 1 when using background color as inverted foreground color.

[chabou]

Or do you want a new invertedForeground in theme (defaulted to backgroundColor)?

I can make a PR

[Eugeny]

I think having an invertedForeground would be a more flexible solution

[Tyriar]

I think it could work if alpha is forced to 1 when using background color as inverted foreground color.

In the interest of keeping the API simpler/slimmer I think this option would work fine, unless there's a real case where an alpha of 1 doesn't make sense (we already force alpha 1 on cells with background when background transparency is on).

[Eugeny]

@Tyriar if you mean forcing the alpha component of backgroundColor to 1 while keeping its RGB as is, I'm in.

[chabou]

@Eugeny That's what I mean :)

@Tyriar I'll try to work on a PR with this solution soon.

[sukima]

@chabou What is the status of this? How can we help? This issue is blocker for me!

[Tyriar]

@sukima we're just waiting on a PR for this if you want to work on it. The proposal above is to when the bg color is used as the fg then always force alpha to be 1 (opaque). This will need to be handled in both canvas and dom renderers:

• https://github.com/xtermjs/xterm.js/blob/master/src/renderer/TextRenderLayer.ts
• https://github.com/xtermjs/xterm.js/blob/master/src/renderer/dom/DomRendererRowFactory.ts

[Eugeny]

@Tyriar here's my attempt at this for the WebGL renderer: Eugeny@cf48304

However, even though the color logic is fine, it leads to the reverse text looking "chipped" - see here:

[Tyriar]

I made a comment earlier but deleted it as it wasn't even using your branch... 🤦‍♂

@Eugeny isn't this blocked on #2252 for webgl?

[Eugeny]

This needs to be done for both renderers - I just started with the webgl one for no specific reason.

[Tyriar]

We need to translate transparent to #000000 here:

xterm.js/addons/xterm-addon-webgl/src/atlas/WebglCharAtlas.ts

Lines 231 to 236 in 8b5c48f

	const bg = this._config.colors.background.css;
	if (bg.length === 9) {
	// Remove bg alpha channel if present
	return bg.substr(0, 7);
	}
	return bg;

[Eugeny]

Hey guys, is there anything I could do to help you fix this in the WebGL renderer as well?

[jerch]

@Tyriar
On a sidenote: Since we somehow support transparent already for BG, we could extend official support for it in SGR by allowing SGR 48 : 1. The 1 is meant as transparent following the official specs. Not sure though about FG here, no clue how we could even draw that with the DOM renderer (while other renderers could use erase masks). Also, full transparency seems not very useful for FG to me, to begin with. How is a transparent BG supposed to be translated into FG for inverted colors?

[Eugeny]

@jerch the idea is not to make inverted FG transparent, but rather ignore the alpha part of BG: #1898 (comment)

[Eugeny]

Could anyone who knows his way around the renderer take a second look at this? It's pretty much prevents widespread adoption of the webgl renderer.

[sriramkandukuri]

Hi, Any update on this, webgl still has the issue.

[Tyriar]

@Eugeny I think this should be relatively easy to fix if you want to give it a try: #1898 (comment)

Basically something like:

if (color is transparent) {
  set to black
}

[Eugeny]

@Tyriar the color was already #00000000 at that point. There seems to be some weird handling specifically for #000 in place:

When _getForegroundCss() == '#000000':

When _getForegroundCss() == '#010101':

When _getForegroundCss() == '#808080':

Note how higher values make the text less "deep fried".