fa7c1abdf8
This PR introduces a new `ColorType` to allow us to distinguish between `SGR` indexed colors from the 16 color table, the lower half of which can be brightened, and the ISO/ITU indexed colors from the 256 color table, which have a fixed brightness. Retaining the distinction between these two types will enable us to forward the correct `SGR` sequences to conpty when addressing issue #2661. The other benefit of retaining the color index (which we didn't previously do for ISO/ITU colors) is that it ensures that the colors are updated correctly when the color scheme is changed. ## References * This is another step towards fixing the conpty narrowing bugs in issue #2661. * This is technically a fix for issue #5384, but that won't be apparent until #2661 is complete. ## PR Checklist * [x] Closes #1223 * [x] CLA signed. * [x] Tests added/passed * [ ] Requires documentation to be updated * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments The first part of this PR was the introduction of a new `ColorType` in the `TextColor` class. Instead of just the one `IsIndex` type, there is now an `IsIndex16` and an `IsIndex256`. `IsIndex16` covers the eight original ANSI colors set with `SGR 3x` and `SGR 4x`, as well as the brighter aixterm variants set with `SGR 9x` and `SGR 10x`. `IsIndex256` covers the 256 ISO/ITU indexed colors set with `SGR 38;5` and `SGR 48;5`. There are two reasons for this distinction. The first is that the ANSI colors have the potential to be brightened by the `SGR 1` bold attribute, while the ISO/ITO color do not. The second reason is that when forwarding an attributes through conpty, we want to try and preserve the original SGR sequence that generated each color (to the extent that that is possible). By having the two separate types, we can map the `IsIndex16` colors back to ANSI/aixterm values, and `IsIndex256` to the ISO/ITU sequences. In addition to the VT colors, we also have to deal with the legacy colors set by the Windows console APIs, but we don't really need a separate type for those. It seemed most appropriate to me to store them as `IsIndex256` colors, since it doesn't make sense to have them brightened by the `SGR 1` attribute (which is what would happen if they were stored as `IsIndex16`). If a console app wanted a bright color it would have selected one, so we shouldn't be messing with that choice. The second part of the PR was the unification of the two color tables. Originally we had a 16 color table for the legacy colors, and a separate table for the 256 ISO/ITU colors. These have now been merged into one, so color table lookups no longer need to decide which of the two tables they should be referencing. I've also updated all the methods that took a color table as a parameter to use a `basic_string_view` instead of separate pointer and length variables, which I think makes them a lot easier and safer to work with. With this new architecture in place, I could now update the `AdaptDispatch` SGR implementation to store the ISO/ITU indexed colors as `IsIndex256` values, where before they were mapped to RGB values (which prevented them reflecting any color scheme changes). I could also update the `TerminalDispatch` implementation to differentiate between the two index types, so that the `SGR 1` brightening would only be applied to the ANSI colors. I've also done a bit of code refactoring to try and minimise any direct access to the color tables, getting rid of a lot of places that were copying tables with `memmove` operations. I'm hoping this will make it easier for us to update the code in the future if we want to reorder the table entries (which is likely a requirement for unifying the `AdaptDispatch` and `TerminalDispatch` implementations). ## Validation Steps Performed For testing, I've just updated the existing unit tests to account for the API changes. The `TextColorTests` required an extra parameter specifying the index type when setting an index. And the `AdapterTest` and `ScreenBufferTests` required the use of the new `SetIndexedXXX` methods in order to be explicit about the index type, instead of relying on the `TextAttribute` constructor and the old `SetForeground` and `SetBackground` methods which didn't have a way to differentiate index types. I've manually tested the various console APIs (`SetConsoleTextAttribute`, `ReadConsoleOutputAttribute`, and `ReadConsoleOutput`), to make sure they are still setting and reading the attributes as well as they used to. And I've tested the `SetConsoleScreenBufferInfoEx` and `GetConsoleScreenBufferInfoEx` APIs to make sure they can read and write the color table correctly. I've also tested the color table in the properties dialog, made sure it was saved and restored from the registry correctly, and similarly saved and restored from a shortcut link. Note that there are still a bunch of issues with the color table APIs, but no new problems have been introduced by the changes in this PR, as far as I could tell. I've also done a bunch of manual tests of `OSC 4` to make sure it's updating all the colors correctly (at least in conhost), and confirmed that the test case in issue #1223 now works as expected.
149 lines
4.7 KiB
C++
149 lines
4.7 KiB
C++
// Copyright (c) Microsoft Corporation.
|
|
// Licensed under the MIT license.
|
|
|
|
#include "precomp.h"
|
|
#include "TextColor.h"
|
|
|
|
bool TextColor::IsLegacy() const noexcept
|
|
{
|
|
return IsIndex16() || (IsIndex256() && _index < 16);
|
|
}
|
|
|
|
bool TextColor::IsHighColor() const noexcept
|
|
{
|
|
return IsRgb() || (IsIndex256() && _index >= 16);
|
|
}
|
|
|
|
bool TextColor::IsIndex16() const noexcept
|
|
{
|
|
return _meta == ColorType::IsIndex16;
|
|
}
|
|
|
|
bool TextColor::IsIndex256() const noexcept
|
|
{
|
|
return _meta == ColorType::IsIndex256;
|
|
}
|
|
|
|
bool TextColor::IsDefault() const noexcept
|
|
{
|
|
return _meta == ColorType::IsDefault;
|
|
}
|
|
|
|
bool TextColor::IsRgb() const noexcept
|
|
{
|
|
return _meta == ColorType::IsRgb;
|
|
}
|
|
|
|
// Method Description:
|
|
// - Sets the color value of this attribute, and sets this color to be an RGB
|
|
// attribute.
|
|
// Arguments:
|
|
// - rgbColor: the COLORREF containing the color information for this TextColor
|
|
// Return Value:
|
|
// - <none>
|
|
void TextColor::SetColor(const COLORREF rgbColor) noexcept
|
|
{
|
|
_meta = ColorType::IsRgb;
|
|
_red = GetRValue(rgbColor);
|
|
_green = GetGValue(rgbColor);
|
|
_blue = GetBValue(rgbColor);
|
|
}
|
|
|
|
// Method Description:
|
|
// - Sets this TextColor to be a legacy-style index into the color table.
|
|
// Arguments:
|
|
// - index: the index of the colortable we should use for this TextColor.
|
|
// - isIndex256: is this a 256 color index (true) or a 16 color index (false).
|
|
// Return Value:
|
|
// - <none>
|
|
void TextColor::SetIndex(const BYTE index, const bool isIndex256) noexcept
|
|
{
|
|
_meta = isIndex256 ? ColorType::IsIndex256 : ColorType::IsIndex16;
|
|
_index = index;
|
|
}
|
|
|
|
// Method Description:
|
|
// - Sets this TextColor to be a default text color, who's appearance is
|
|
// controlled by the terminal's implementation of what a default color is.
|
|
// Arguments:
|
|
// - <none>
|
|
// Return Value:
|
|
// - <none>
|
|
void TextColor::SetDefault() noexcept
|
|
{
|
|
_meta = ColorType::IsDefault;
|
|
}
|
|
|
|
// Method Description:
|
|
// - Retrieve the real color value for this TextColor.
|
|
// * If we're an RGB color, we'll use that value.
|
|
// * If we're an indexed color table value, we'll use that index to look up
|
|
// our value in the provided color table.
|
|
// - If brighten is true, and we've got a 16 color index in the "dark"
|
|
// portion of the color table (indices [0,7]), then we'll look up the
|
|
// bright version of this color (from indices [8,15]). This should be
|
|
// true for TextAttributes that are "Bold" and we're treating bold as
|
|
// bright (which is the default behavior of most terminals.)
|
|
// * If we're a default color, we'll return the default color provided.
|
|
// Arguments:
|
|
// - colorTable: The table of colors we should use to look up the value of
|
|
// an indexed attribute from.
|
|
// - defaultColor: The color value to use if we're a default attribute.
|
|
// - brighten: if true, we'll brighten a dark color table index.
|
|
// Return Value:
|
|
// - a COLORREF containing the real value of this TextColor.
|
|
COLORREF TextColor::GetColor(std::basic_string_view<COLORREF> colorTable,
|
|
const COLORREF defaultColor,
|
|
bool brighten) const noexcept
|
|
{
|
|
if (IsDefault())
|
|
{
|
|
if (brighten)
|
|
{
|
|
FAIL_FAST_IF(colorTable.size() < 16);
|
|
// See MSFT:20266024 for context on this fix.
|
|
// Additionally todo MSFT:20271956 to fix this better for 19H2+
|
|
// If we're a default color, check to see if the defaultColor exists
|
|
// in the dark section of the color table. If it does, then chances
|
|
// are we're not a separate default color, instead we're an index
|
|
// color being used as the default color
|
|
// (Settings::_DefaultForeground==INVALID_COLOR, and the index
|
|
// from _wFillAttribute is being used instead.)
|
|
// If we find a match, return instead the bright version of this color
|
|
for (size_t i = 0; i < 8; i++)
|
|
{
|
|
if (colorTable.at(i) == defaultColor)
|
|
{
|
|
return colorTable.at(i + 8);
|
|
}
|
|
}
|
|
}
|
|
|
|
return defaultColor;
|
|
}
|
|
else if (IsRgb())
|
|
{
|
|
return _GetRGB();
|
|
}
|
|
else if (IsIndex16() && brighten)
|
|
{
|
|
return colorTable.at(_index | 8);
|
|
}
|
|
else
|
|
{
|
|
return colorTable.at(_index);
|
|
}
|
|
}
|
|
|
|
// Method Description:
|
|
// - Return a COLORREF containing our stored value. Will return garbage if this
|
|
//attribute is not a RGB attribute.
|
|
// Arguments:
|
|
// - <none>
|
|
// Return Value:
|
|
// - a COLORREF containing our stored value
|
|
COLORREF TextColor::_GetRGB() const noexcept
|
|
{
|
|
return RGB(_red, _green, _blue);
|
|
}
|