[Gs-devel] Re: long gx_color_index

[L. Peter Deutsch]

> typedef uint * gx_color_index;
> 
> 0-th element is equal to the old value.
> The majority of old functions never need to access other elements.

Functions that "know" they are dealing with pixels that fit in a uint can do
this, like the ones in the gdevm## files.  But functions that handle general
gx_color_index values cannot.  I think there are more of the latter (aside
from drivers).

> Too complicated. I believe that old drivers never use longer color indices.
> What is an use of long indices in a CMYK printer ???
> Call tint transform before passing to the driver.

It seems to me that that every place in the graphics library that passes a
gx_color_index value to a driver would have to check whether the value fits
in a uint or not, and call one of two different driver procedures depending
on the result.  There are dozens of places like this, and it is quite a
burden on the graphics library.  Is this really what you had in mind?
Wouldn't calling a new procedure and letting it reflect back to the old one
be simpler?

Defining a new type name is absolutely essential in any case, because the
semantics are different.  I have been burned badly by trying to change the
definition of a type without changing its name: C's type system is weak, and
the compiler will not catch all the places that need editing.  Also, if we
change a "by value" type to a pointer type, we now have entirely new memory
management issues -- who allocates the values, who frees them, etc. --
requiring deeper analysis when changing the code.  On the other hand, using
a pointer makes transmitting values between procedures inexpensive.

The compilation experiment I did yesterday used TEST_CINDEX_STRUCT, which
makes gx_color_index a by-value structure.  Today I tried
TEST_CINDEX_POINTER.  Only 38 files failed to compile, but there were many
warnings about casts between pointers and integers, which are also errors
(gcc treats type errors as warnings!!!).

If we really want to expand gx_color_index beyond 64 bits (assuming that all
modern C compilers have a 64-bit unsigned type -- does anyone know the
answer about this?), then I think I would favor the pointer approach, even
though it would require much more careful work, simply because it doesn't
impose any fixed limit at all.

There is another completely different approach one could take, which is to
change Ghostscript from "chunky" to "planar" processing.  This would be a
radical change, requiring a redesign of many parts of the graphics library,
but since Raph is thinking about replacing the entire graphics library
anyway, it might be worth considering.  I suspect the Adobe RIPs are planar
internally; going planar naturally eliminates the limit on the number of
components, and makes certain operations much more efficient (color
halftoning in particular) while not slowing down others terribly.

> Here is one more idea. It consists of 3 parts :

I don't like this idea at all.  As I understand it, it creates a need for
huge amounts of additional storage for any driver whose pixels won't fit in
a uint.

-- 

L. Peter Deutsch     |    Aladdin Enterprises   |  203 Santa Margarita Ave.
ghost at aladdin.com    |  http://www.aladdin.com  |  Menlo Park, CA 94025

	The future of software is at http://www.opensource.org