RGB colour values for CMD colours don't update as you select new colours. #1619

Closed
opened 2026-01-30 22:32:14 +00:00 by claunia · 9 comments
Owner

Originally created by @zadjii-msft on GitHub (Jun 12, 2019).

Moved from MSFT:20246999

RGB colour values for CMD colours don't update as you select new colours.

They don't match the selected colour when you change the item (like foreground or background). They only change when you pick a new colour from the swatch. See repro screenshots.

This is not a regression (from RS4, even), and is a UI issue only.

Originally created by @zadjii-msft on GitHub (Jun 12, 2019). Moved from MSFT:20246999 RGB colour values for CMD colours don't update as you select new colours. They don't match the selected colour when you change the item (like foreground or background). They only change when you pick a new colour from the swatch. See repro screenshots. This is not a regression (from RS4, even), and is a UI issue only.
Author
Owner

@carlos-zamora commented on GitHub (Aug 31, 2019):

@microsoft/windows-console-team Can we attach the "repro screenshots" described above here?

@carlos-zamora commented on GitHub (Aug 31, 2019): @microsoft/windows-console-team Can we attach the "repro screenshots" described above here?
Author
Owner

@DHowett-MSFT commented on GitHub (Sep 3, 2019):

Here's the deal:

printf '\e[38;5;134mColor_134_Before\e[m\n'
printf '\e]4;134;rgb:ff/00/ff\e\'
printf '\e[38;5;134mColor_134_after\e[m\n'
printf '\e]4;134;rgb:00/00/ff\e\'
printf '\e[38;5;134mColor_134_after_2\e[m\n'

These five lines do the following:

  1. Print something in color 134 using CSI m
  2. Change the definition of color 134 to be #FF00FF using OSC 4
  3. Print something in color 134
  4. Change the definition of color 134 to be #0000FF
  5. Print something in color 134

It looks like this:

image

This is actually wrong! Other terminal emulators remember that all three lines are in "color 134", and when color 134 changes definition, the existing lines change too!

This is what it looks like in xterm:

image

@DHowett-MSFT commented on GitHub (Sep 3, 2019): Here's the deal: ```sh printf '\e[38;5;134mColor_134_Before\e[m\n' printf '\e]4;134;rgb:ff/00/ff\e\' printf '\e[38;5;134mColor_134_after\e[m\n' printf '\e]4;134;rgb:00/00/ff\e\' printf '\e[38;5;134mColor_134_after_2\e[m\n' ``` These five lines do the following: 1. Print something in color 134 using CSI m 1. Change the definition of color 134 to be `#FF00FF` using OSC 4 1. Print something in color 134 1. Change the definition of color 134 to be `#0000FF` 1. Print something in color 134 It looks like this: ![image](https://user-images.githubusercontent.com/14316954/64140922-0e0fb680-cdbb-11e9-804f-60b2bf94f066.png) This is actually wrong! Other terminal emulators remember that all three lines are in "color 134", and when color 134 _changes definition_, the existing lines change too! This is what it looks like in xterm: ![image](https://user-images.githubusercontent.com/14316954/64141050-85dde100-cdbb-11e9-80d5-b71af804c424.png)
Author
Owner

@mdtauk commented on GitHub (Sep 3, 2019):

So using a UWP/XAML metaphor...

You believe the console colours should be treated like ThemeResources and not Static ones. So they update as the "theme"/colour scheme changes?

What kind of perf impact would that have?

@mdtauk commented on GitHub (Sep 3, 2019): So using a UWP/XAML metaphor... You believe the console colours should be treated like ThemeResources and not Static ones. So they update as the "theme"/colour scheme changes? What kind of perf impact would that have?
Author
Owner

@DHowett-MSFT commented on GitHub (Sep 3, 2019):

You believe ...

Well, xterm (the reference implementation) does it this way, so it is less a matter of belief and more a matter of correctness. 😉

We already store color indices for runs using indices 0-16; it should be a fairly minimal perf impact to broaden that to indices 0-255 and trigger a frame repaint when the color table changes.

In general, I think it may not have been the best choice for us to always store the RGB color in the attribute run -- we should have only done so for 38;2 and 48;2 (true color) runs. It unnecessarily couples the color table and attribute storage.

@DHowett-MSFT commented on GitHub (Sep 3, 2019): > You believe ... Well, xterm (the reference implementation) does it this way, so it is less a matter of belief and more a matter of correctness. :wink: We already store color indices for runs using indices 0-16; it should be a fairly minimal perf impact to broaden that to indices 0-255 and trigger a frame repaint when the color table changes. In general, I think it may not have been the best choice for us to always store the RGB color in the attribute run -- we should have only done so for `38;2` and `48;2` (true color) runs. It unnecessarily couples the color table and attribute storage.
Author
Owner

@DHowett-MSFT commented on GitHub (Sep 3, 2019):

But yeah, actually, ThemeResource is an apt analogy. You’ve also helped me figure out what a ThemeResource is meant to do!

@DHowett-MSFT commented on GitHub (Sep 3, 2019): But yeah, actually, ThemeResource is an apt analogy. You’ve also helped me figure out what a ThemeResource is meant to do!
Author
Owner

@mdtauk commented on GitHub (Sep 3, 2019):

@DHowett-MSFT And I learned that there is an existing spec that Windows Terminal is working towards, other than Bash/Unix compatibility for the WSL profiles.

@mdtauk commented on GitHub (Sep 3, 2019): @DHowett-MSFT And I learned that there is an existing spec that Windows Terminal is working towards, other than Bash/Unix compatibility for the WSL profiles.
Author
Owner

@DHowett-MSFT commented on GitHub (Sep 3, 2019):

Whoops, I totally messed up on this bug. 'm going to move the comments later to the correct issue for OSC 4.

@carlos-zamora the actual issue is this one:

image

These radio buttons don't change the RGB boxes, but they do seemingly select the correct color swatch below.

@DHowett-MSFT commented on GitHub (Sep 3, 2019): Whoops, I totally messed up on this bug. 'm going to move the comments later to the _correct_ issue for OSC 4. @carlos-zamora the actual issue is this one: ![image](https://user-images.githubusercontent.com/14316954/64144910-75356700-cdcb-11e9-92ae-120fab345db6.png) These radio buttons don't change the RGB boxes, but they do seemingly select the correct color swatch below.
Author
Owner

@zadjii-msft commented on GitHub (Sep 3, 2019):

I was going to say, the issue Dustin's talking about is #1223, which is related, but different. I have a fix ready for #1223, which is almost exactly what Dustin suggested.

@zadjii-msft commented on GitHub (Sep 3, 2019): I was going to say, the issue Dustin's talking about is #1223, which is related, but _different_. I have a fix ready for #1223, which is almost exactly what Dustin suggested.
Author
Owner

@ghost commented on GitHub (Feb 3, 2022):

:tada:This issue was addressed in #12099, which has now been successfully released as Windows Terminal Preview v1.13.10336.0.🎉

Handy links:

@ghost commented on GitHub (Feb 3, 2022): :tada:This issue was addressed in #12099, which has now been successfully released as `Windows Terminal Preview v1.13.10336.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.13.10336.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#1619