Re: Removing assumption of unsigned long pixel values for colours

[Alex Gramiak <agrambot@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> It's not as much of an issue with the X+Cairo backend since the colour
>> is calculated from XQueryColors which returns an XColor, but the backend
>> I'm working on uses gdk_rgba_parse to query colors, which returns a
>> GdkRGBA (which is compatible with Cairo's). This means that a conversion
>> from the quadruple into unsigned long has to be done for every colour
>> queried.
>
> Such conversion needs about 2 to 3 machine instructions on modern
> hardware, so why is it a problem?  If you are annoyed by seeing it in
> the sources all the time, then a macro or an inline function should
> take care of that.

It's certainly possible that I'm overestimating the cost of the
conversions. It just doesn't seem good to have to do this conversion for
every draw operation.

Perhaps I should follow the old adage and just use unsigned long with
conversions first and benchmark after.

> Are there other issues that caused you to propose this change?

Not directly, but to avoid the conversions I did add additional
complexity by using a local tagged union that I feel is too much
trouble. I figured that I'd float this option by before changing
strategies.

> I see a couple of disadvantages with your proposal:
>
>   . it leaks to platform-independent parts of the code representation
>     that is specific to one platform, something that goes against
>     everything you've been doing lately in your other work

I'm not sure what leaks you're referring to here. The cases that use
.pixel directly should only be in the TTY-specific or X-specific code.

>   . the union you propose has no indication which of its
>     interpretations is being used, which will lead to bugs

I considered that, but as it looks like faces are tied to frames (which
are tied to terminals), then the type shouldn't need to be checked as
long as the terminal-independent code doesn't alter it.

> (larger structures slow down Emacs)

More so than other programs?

>> Also, AFAIU a GdkRGBA wouldn't necessarily convert into an unsigned long
>> without losing precision.
>
> If we want to increase the number of bits per pixel we support in
> Emacs, we need to do that for all the platforms.  Currently, they all
> are aligned on 32 bpp, AFAIK.  If indeed there will be loss of
> information (and I'd like to see some evidence to that first), then we
> need to move all the platforms to higher precision, not just one.

Wouldn't it only need to be done for platforms that support a higher
pixel depth?

gdk_rgba_parse uses pango_color_parse, which returns a PangoColor (48
bpp RGB), and normalizes each component over 2^16. If using either
CAIRO_FORMAT_RGB30 (30 bpp RGB) with image surfaces or using the OpenGL
backend (which I believe the GTK Wayland backend uses), then storing
ARGB values into an unsigned long would mean lost precision that could
have been used.