Re: Removing assumption of unsigned long pixel values for colours

[Alex Gramiak <agrambot@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.
>
> No, I meant the RGBA representation.  The integer color values are our
> current abstraction.

Do you mean the conditional GdkRGBA in emacs_color? I don't think that's
really any different than the platform-specific output_data types. What
would the alternatives be in the case that a single representation
couldn't handle all supported platforms?

>> > (larger structures slow down Emacs)
>> 
>> More so than other programs?
>
> Why should other programs matter here?  I don't want to have slow-down
> in the inner-most loops of Emacs, because that causes legitimate user
> complaints.  Faces are used in redisplay.

I meant if there was any specific reason to Emacs that slightly larger
structures would cause a non-negligible slowdown. In any case, I would
have thought that the conversions would cause more of a slow-down, but
we can perhaps find that out later.

>> > 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?
>
> No, we want all platforms to support the same color representation,
> for various good reasons.  For example, platform-independent
> representation of standard colors.

Ideally, but if there is no way to represent a certain precision on a
particular platform, and if the size of structures is of concern to you,
then would it not make sense to only support the maximum precision
possible?

I meant something along the lines of:

  #ifdef <Using a platform needing 64-bits>
  typedef unsigned long long emacs_pixel;
  #else
  typedef unsigned long emacs_pixel;
  #endif

>> 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.
>
> Once again, I'm okay with discussing a change for all the platforms,
> but it needs to show benefits for all of them, or at least a
> majority.

I'm not sure about the situation on other platforms, but IMO it would be
worthwhile to discuss a change even if it benefits only a single
supported platform as long as it doesn't introduce non-trivial
complexity to the other platforms (such as the above #ifdef).

>   What you describe could mean a use of a single 'double' for
> a color; we definitely don't need 4 'double's yet.

I'm not sure that a single double would suffice here.

P.S. You mention "platform-independent representation of standard
colors", but isn't the unsigned long used differently on different
platforms already? NS and X seem to use it as indices to color tables
(AFAIU X uses the pixel value to lookup a 48-bpp RGB triplet and store
it in an XColor), and w32 uses it to embed a COLORREF.