Re: Removing assumption of unsigned long pixel values for colours

[Eli Zaretskii]

> From: Alex Gramiak <address@hidden>
> Cc: address@hidden, Alan Third <address@hidden>
> Date: Sat, 04 May 2019 17:04:43 -0600
> 
> > Can you describe the goal, in terms of the advantages of such a
> > representation, and the limitations of the existing representation
> > that it attempts to resolve?  I think whether we want to make this
> > change depends on what will we gain from the changes.
> 
> The goal is to avoid frequent conversions between the colour type used
> in Emacs and the colour type used in drawing backends. In my case, the
> drawing backend is Cairo (GTK), which uses 4 double values in the range
> [0, 1] for ARGB. One can see the conversion from XColor to Cairo's
> format in x_set_cr_source_with_gc_foreground and
> x_set_cr_source_with_gc_background.
> 
> 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.

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

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

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

  . the structures which use colors will now be significantly larger,
    because instead of a single 32-bit or 64-bit number the union will
    need to hold 4 64-bit double-precision numbers (larger structures
    slow down Emacs)

Against these disadvantages, what are the advantages? just the fact
that you can carry the native color representation of some platform?
IMO, that's not enough to justify such changes.

> 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.