Re: Removing assumption of unsigned long pixel values for colours

[Alex Gramiak]

Eli Zaretskii <address@hidden> writes:

>> From: Alex Gramiak <address@hidden>
>> Date: Sat, 04 May 2019 12:08:34 -0600
>> 
>> I've attached a WIP patch (for illustrative purposes) creating a new
>> union, emacs_color, that removes the single type limitation for the
>> internal representation of colours. This approach is intended to be used
>> with a new backend that I'm working on which uses a quadruple of
>> normalized double values for each colour rather than a single pixel
>> value. Using a union would avoid having to frequently convert between
>> the two representations.
>
> 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.

Using a union for stored colours would allow for direct access/storage
of the colours rather than conversions for every query and drawing
operation.

Also, AFAIU a GdkRGBA wouldn't necessarily convert into an unsigned long
without losing precision.

It might also help simplify the NS side to use NSColor objects directly
rather than using the unsigned long values as indices to an
ns_color_table (CC'd Alan to confirm/deny).

>> Question: In realize_gui_face, why is a defaulted underline colour set
>> to 0 when defaulted overline/strike-through colours are set to the
>> foreground colour? The comment above the underline case mentions that
>> it's the same as the foreground colour, so should it be explicitly set
>> there as well?
>
> realize_gui_face just sets a flag, the implementation should be in the
> *term.c back-ends.  When that flag is set, the color of the underline
> should be disregarded and taken from the current foreground color. On
> MS-Windows, the underline changes its color according to the
> foreground color of the text it underlines.  Don't you see the same on X?

Yes, I didn't mean that the underline colour wasn't inherited; I was
just referring to the value that underline_color is set to when
defaulted:

      face->underline_defaulted_p = true;
      face->underline_color = 0;

where the other defaulted cases set the colour explicitly (perhaps just
being overly cautious?):

      face->overline_color = face->foreground;
      face->overline_color_defaulted_p = true;

      face->strike_through_color = face->foreground;
      face->strike_through_color_defaulted_p = true;

AFAICS the value set doesn't matter (*_draw_glyph_string just checks the
flags), but I wanted to check that there wasn't a reason that
underline_color was different that I was missing.