RE: 688177 Eliminate the 64 bit pixel size limit

Igor,

I am not sure about how your scheme works.  I did look at the URL that you
gave in your email and also at the patches that you posted to the bug 688177
bug report.  However I am still not sure about what you are doing.  If I am
wrong about what you are doing then let me know.

It looks like you are changing a gx_color_index to be a non integer type.  If
so then this is both good and bad.  The major advantage is that once that change
is made, then it will probably be fairly easy to support things like a very
large number of colorants.  The major disadvantages of using a non integer type
are that changes have to be made throughout the entire graphics library and all
of the current device drivers.  This is a very large effort.  Besides changing
every reference to a gx_color_index type variable, there are issues with memory
management for things like changing raster buffer sizes as spot colorants are
found while processing a file.  This sort of change is also likely to make
the general operation of the graphics library slower.  I do see that you seem
to have a scheme which allows switching between an integer an non integer types
at compile time.  This does eliminate some worries but it also creates other
issues about testing the different versions.

My first email gave a list of the advantages and disadvantages of my scheme.
I would like to emphasize the advantages of this method include that it is quick
to implement, it does support 64 (or more) colorants and it does not affect the
majority of the graphics library or any other device.  This makes issues about
support of customer and GPL devices much simpler and the likelihood of introducing
bugs into the graphics library is eliminated.


Dan


-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Igor V.
Melichev
Sent: Wednesday, August 31, 2005 6:46 AM
To: Gs-Code-Review; [email protected]
Cc: Miles Jones
Subject: Re: [gs-code-review] 688177 Eliminate the 64 bit pixel size
limit


Dan,

Your approach changes a very strong restriction to a strong one.
IMO there is a way to change it to a very weak one,
at least for the kernel of the graphics library :

     color components <= 64
     color component bits <= 16

See gxcindex.h Revision: 1.7.2.2, Mon Jun 20 22:47:12 2005 UTC (2 months, 1
week ago) by igor
http://cvs.ghostscript.com/cgi-bin/viewcvs.cgi/cvs/ghostscript/gs/src/gxcindex.h?rev=1.7.2.2&only_with_tag=COLOR_INDEX_2_64&view=log

Igor.

----- Original Message -----
From: "Dan Coby" <[email protected]>
To: "Gs-Code-Review" <[email protected]>
Sent: Wednesday, August 31, 2005 11:25 AM
Subject: [gs-code-review] 688177 Eliminate the 64 bit pixel size limit

[...skipped...]

>  Number of non zero components    Index bits Bits per component
> 0 to 5    24      8
>    6    16    8
>    7     8    8
>    8          8    7
>    9     8    6
>   10     8    5
>   11     8    5
>   12     8    4
>   13     8    4
>   14     8    4
>     More than 14 Not enclosable

_______________________________________________
gs-code-review mailing list
[email protected]
http://www.ghostscript.com/mailman/listinfo/gs-code-review