Re: Removing assumption of unsigned long pixel values for colours

[Eli Zaretskii]

> From: Alex Gramiak <address@hidden>
> Cc: address@hidden
> Date: Mon, 06 May 2019 09:11:18 -0600
> 
> Eli Zaretskii <address@hidden> 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?

Yes.

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

I don't know, we will need to discuss this when we have an actual
problem.  For now this is a hypothetical problem.

> I meant if there was any specific reason to Emacs that slightly larger
> structures would cause a non-negligible slowdown.

It could happen if enlarging a structure makes it large enough to not
fit into a cache line.  So we should do this only if really necessary,
and then very cautiously.  The display engine already juggles some
very large structures.

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

I think you are mistaken, doing simple arithmetics, even FP
arithmetics, is lightning fast on modern machines, specially since
they have several execution units that work in parallel.

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

This will bite us at some point because we currently more or less
expose the X color values to users.

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

COLORREF is just the RGB representation of a color, see

  https://docs.microsoft.com/en-us/windows/desktop/gdi/colorref

Our color abstraction is also RGB representation, which AFAIR comes
from X.  Maybe X uses something different nowadays, but since the RGB
color descriptions are exposed to Lisp, changing that would be tricky.
So conversion where needed is TRT, I think.  And IME it rarely is
expensive enough to matter, so I don't think the need to convert per
se justifies significant changes in interfaces and infrastructure.