Re: [hackers] [st][PATCH] Fix truecolor being slightly inaccurate
On Sun, 6 Mar 2022 21:07:41 +0800 Yutao Yuan wrote: > The displayed color in truecolor mode is sometimes darker than > requested. The inaccuracy can be verified with the following example, > which should paint a white block but instead produces color #fefefe. > > printf '\e[38;2;255;255;255m\u2588\u2588\u2588\n' I'm also getting #FEFEFE. The only thing I have found that might explain this discrepancy is this section from XParseColor(3): >An RGB Device specification is identified by the prefix “rgb:” > and conforms to the following syntax: > >rgb:// > >, , := h | hh | hhh | >h := single hexadecimal digits (case insignificant) > >Note that h indicates the value scaled in 4 bits, hh the > value scaled in 8 bits, hhh the value scaled in 12 bits, and the > value scaled in 16 bits, respectively. > >For backward compatibility, an older syntax for RGB Device is > supported, but its continued use is not encouraged. The syntax is > an initial sharp sign character followed by a numeric > specification, in one of the following formats: > >#RGB(4 bits each) >#RRGGBB (8 bits each) >#RRRGGGBBB (12 bits each) ># (16 bits each) > >The R, G, and B represent single hexadecimal digits. When > fewer than 16 bits each are specified, they represent the most > significant bits of the value (unlike the “rgb:” syntax, in which > values are scaled). For example, the string “#3a7” is the same as > “#3000a0007000”. Maybe different implementations of one of the used libraries (Xft->XRender->Xlib) use different ways to get from an XRenderColor to a XColor. One of them might use XParseColor with the rgb:rr/gg/bb format, explaining how some people are getting #FF.
Re: [hackers] [st][PATCH] Fix truecolor being slightly inaccurate
Hi Yutao, > The displayed color in truecolor mode is sometimes darker than > requested. The inaccuracy can be verified with the following example, > which should paint a white block but instead produces color #fefefe. > > printf '\e[38;2;255;255;255m\u2588\u2588\u2588\n' I get #ff on both vanilla st and with your patch applied.
[hackers] [st][PATCH] Fix truecolor being slightly inaccurate
The displayed color in truecolor mode is sometimes darker than requested. The inaccuracy can be verified with the following example, which should paint a white block but instead produces color #fefefe. printf '\e[38;2;255;255;255m\u2588\u2588\u2588\n' The truecolor code uses 8-bit color values (0 to 0xff), while X uses 16-bit color values (0 to 0x). Existing code multiplies the value by 256 to make the conversion, but this is incorrect, as it maps 0xff to 0xff00, not 0x. This patch multiplies the value by 257 instead, which is the correct formula (0xff * 257 == 0x). --- x.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/x.c b/x.c index cd96575..f012539 100644 --- a/x.c +++ b/x.c @@ -69,9 +69,9 @@ static void ttysend(const Arg *); /* macros */ #define IS_SET(flag) ((win.mode & (flag)) != 0) -#define TRUERED(x) (((x) & 0xff) >> 8) -#define TRUEGREEN(x) (((x) & 0xff00)) -#define TRUEBLUE(x) (((x) & 0xff) << 8) +#define TRUERED(x) x) & 0xff) >> 16) * 257) +#define TRUEGREEN(x) x) & 0xff00) >> 8) * 257) +#define TRUEBLUE(x) x) & 0xff)) * 257) typedef XftDraw *Draw; typedef XftColor Color; -- 2.35.0
