Skip to content

Make sure background color is opaque when attrs are reversed #5509

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 23, 2020
Merged

Make sure background color is opaque when attrs are reversed #5509

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions src/cascadia/TerminalCore/terminalrenderdata.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -59,8 +59,8 @@ const COLORREF Terminal::GetBackgroundColor(const TextAttribute& attr) const noe
{
const auto bgColor = attr.CalculateRgbBackground({ _colorTable.data(), _colorTable.size() }, _defaultFg, _defaultBg);
// We only care about alpha for the default BG (which enables acrylic)
// If the bg isn't the default bg color, then make it fully opaque.
if (!attr.BackgroundIsDefault())
// If the bg isn't the default bg color, or reverse video is enabled, make it fully opaque.
if (!attr.BackgroundIsDefault() || WI_IsFlagSet(attr.GetMetaAttributes(), COMMON_LVB_REVERSE_VIDEO))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I may file a followup TODO: the foreground should become transparent in this case, which would just be wild. Also, it simply wouldn't work, because we would need to push it on as a clipping layer when we draw the background ;P

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On a related note, we may also want to consider whether a background color that simply matches the default background should also be made transparent. Right now, if I set my background to \e[40m or \e[48;5;0m those colors will also be treated as transparent. Once #2661 is fixed, though, that wouldn't be the case - only an explicit default background would be transparent. Maybe that's the way it should be - I don't what most people expect from this feature. We just need to be aware that the current behaviour is going to change after #2661 if we leave things as they are.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's the right thing to do (separate 40/48 and 37/38), but we may need to make it opt-in or opt-out for the ConPTY consumer. Per #293 (comment), this is one of those sad compatibility hacks.

Because legacy console applications could never emit colors that weren't in the default 16, we chose to make their explicit requests for backgrounds that matched the "default" buffer background (in the legacy 4-bit sense) and foreground into requests for the "default" when they came out of the PTY. 😕

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there weren't so many apps with a dependency on the layout of a console text attribute or the SetConsoleTextAttributes API, I'd be gung-ho for it. After all, conhost itself has a mode that lets us differentiate them. It does look rather garish, however:

(from Rich's blog post about that)
image

{
return 0xff000000 | bgColor;
}
Expand Down