Re: Color Class

Rasmus Lerdorf wrote: > > > > > It will probably more flexible to not store all differents colors > > > > value in the same array. There are many colors standart (Rasmus told > > > > us about cmyk and spots b.e.) and maybe pantone and others stuffs like > > > > that. The array will grow too much. One array per colortype > > > > PEAR_Colors_RGB PEAR_Colors_CMYK,... ? We don't need to include all > > > > colors and maybe more modular. > > > > > > Or store it in one format and figure out the appropriate conversion > > > algorithms to the various other formats. Some cannot be automatically > > > converted, but for the ones that can there is no reason to duplicate the > > > data. > > > > > > > It's not a "space" problem it's a "speed" problem. Think on > > gradients or > > "show colors" operations. > > But a "space" problem becomes a speed problem since this is done in user > space on a per-request basis. For this to not be a speed issue you'd need > to write this in C and have it initialized just once in the module startup > hook. > Well, this is of course true but would one like to complicate his life so much for this stuff?. I would propose to include only the "basic" colors for the imaginary PEAR_Colors class, the ones that comes in the /usr/X11R6/lib/X11/rgb.txt file for example, source of other programs like "gcolorsel". There are "only" 735 entries there and if them are splitted into one file per color mode, the time to process it won't be too significative and the speed for selecting many colors will be reduced a lot. You the "king of cache" can't be against that thinking in a simple php solution ;). You know, we can always provide silly scripts for generating the php code from the properly conversion functions. Tomas V.V.Cox