-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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.
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
Simplify the handling of alpha values in the color table #11900
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My one concern is that I can't run the local settings tests, and I assume they don't run in CI either, so it's possible that something might be broken there. I don't think that's likely, but it would be good if someone could confirm that.
std::array<COLORREF, COLOR_TABLE_SIZE> expectedCampbellTable; | ||
const auto campbellSpan = gsl::make_span(expectedCampbellTable); | ||
Utils::InitializeColorTable(campbellSpan); | ||
Utils::SetColorTableAlpha(campbellSpan, 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This shouldn't be necessary, because the COLORREF
s are automatically initialized with zero alpha when cast from til::color
(which is what happens in the InitializeColorTable
method).
VERIFY_ARE_EQUAL(ARGB(0, 0x45, 0x67, 0x89), terminalSettings4->CursorColor()); // from profile (no color scheme) | ||
VERIFY_ARE_EQUAL(RGB(0x23, 0x45, 0x67), terminalSettings2->CursorColor()); // from profile (trumps color scheme) | ||
VERIFY_ARE_EQUAL(RGB(0x34, 0x56, 0x78), terminalSettings3->CursorColor()); // from profile (not set in color scheme) | ||
VERIFY_ARE_EQUAL(RGB(0x45, 0x67, 0x89), terminalSettings4->CursorColor()); // from profile (no color scheme) | ||
VERIFY_ARE_EQUAL(DEFAULT_CURSOR_COLOR, terminalSettings5->CursorColor()); // default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we're no longer including argb.h
, the standard RGB
macro will create COLORREF
s with a zero alpha, which is no different from the previous ARGB
usage here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for cleaning up my mess!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
@msftbot merge this in 10 minutes |
Hello @carlos-zamora! Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:
If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you". |
@msftbot merge this in 10 minutes |
Hello @carlos-zamora! Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:
If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this! Puzzlingly, removing knowledge of alpha and alpha transition from a bunch of these layers will make future work on alpha colors easier. I love it.
Hello @DHowett! Because this pull request has the Do note that I've been instructed to only help merge pull requests of this repository that have been opened for at least 8 hours, a condition that will be fulfilled in about 5 minutes. No worries though, I will be back when the time is right! 😉 p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
🎉 Handy links: |
This PR attempts to minimize the amount of fiddling we do with the alpha
color components, by storing all colors with a zero alpha (the default
for
COLORREF
values) and then leaving it up to the renderer to adjustthe final alpha value as required (which it was already doing anyway).
This gets rid of the
argb.h
header file, which was originally beingused to produce
COLORREF
values with custom alpha components, and thusis no longer required. Anywhere that was using the
ARGB
macro is nowusing a standard
RGB
macro with a 0 alpha.The
Utils::SetColorTableAlpha
method has also been removed, since thatwas only really used to force an alpha of 255 on all the color table
entries, which isn't necessary.
There were also a number of places where we were using
til::color::with_alpha
, to switch alpha components back and forthbetween 0 and 255, which have now been removed. Some of these were
essentially noops, because the
til::color
class already applied theappropriate alpha changes when converting from or to a
COLORREF
.I've manually run a few attribute rendering tests to check that the
colors were still working correctly, and the default background color is
appropriately transparent when in acrylic mode.
Closes #11885