Re: Removing assumption of unsigned long pixel values for colours

[Eli Zaretskii <eliz@gnu.org>]

> From: Alex Gramiak <agrambot@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 05 May 2019 13:35:01 -0600
> 
> 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.

Yes, please.

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

No, I meant the RGBA representation.  The integer color values are our
current abstraction.

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

That "as long as" part is already a potential problem.  And I see
other opportunities for exciting bugs.

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

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

> 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.  What you describe could mean a use of a single 'double' for
a color; we definitely don't need 4 'double's yet.