Re: Removing assumption of unsigned long pixel values for colours

[Alex Gramiak <agrambot@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> Once again: why?

A table lookup would require memory allocation that could be easily
avoided if the integral representation that Emacs uses for colours was
at least 64-bit instead of 32-bit.

> And what table look up do you need, when you originally said that a
> conversion would do?  What am I missing?

I brought up the table lookup as an alternative to the converted
embedding scheme if you weren't okay with widening the integral
representation. Otherwise the embedding could lose precision as
mentioned previously.

> Btw, I think this discussion basically puts the cart before the horse,
> so to speak.  You say you are developing a new back-end, which might
> need these changes, but we never saw that back-end and didn't yet
> decide it's a useful addition to Emacs.  IMO, this is the wrong order
> of discussing this stuff.  let's first see the feature itself, discuss
> its implementation and integration with Emacs, and only after that
> talk about any necessary changes in the infrastructure.  That way, all
> the sides of the discussion will know what's at stake, and the
> discussion becomes more concrete.
>
> OK?

Sure, though I don't know what relevant information is missing; the goal
of this thread was to determine if a certain change is suitable
_assuming_ that such a backend is submitted with the change, and that
the backend needs it (or rather finds it sufficiently useful). I just
wanted to avoid having to implement the union scheme fully and having to
revert it upon review. It turns out that it was good to post this, since
I was assured that using the integral representation is good enough.

I can just restrict the colours to 8bpc in the meantime.