On Mar 29, 2006, at 10:38 AM, Frank Barknecht wrote:
Hallo, João Miguel Pais hat gesagt: // João Miguel Pais wrote:
The reason to use a single number as a color was because 3-component colors in a data structure drawing command just seemed too
unwieldly. But I'm starting to wonder if this was truly a wise decision to
make. The trouble now is it would mean having two versions of every
drawing instruction, yuck!yeah, but once all formats are equally compatible, then in no time
they would be used by all (I think, it sound logical). of couse back- comp would be nice...Personally I think, 1-element colors are easier to handle, especially as we don't have [pak] yet. In an abstraction, I would only need to use one dollar variable to pass a color instead of three, and the required counting of positional arguments in data structure drawing instructions already is *very errorprone*. And using 3-element colors would triple the amount of color arguments to count! I'm already trembling ...
My GEM patches OTOH have a lot of [unpack $1 $2 $3] constructs. Btw: It would be nice if the GEM color objects would accept lists instead of being forced to [unpack 0 0 0] in front of every colorRGB object.
But I admit: Generally colors don't map well to a one-dimensional scale, as the data structure colors show. Colors generally are better mapped to things like a 2-dimensional color circle or to three or four sliders. Encoding RGB color in one float is hard enough, but how to encode RGBA into one float?
This really is a hard question and probably it is another area, where a general mapping abstraction library will be necessary.
Maybe a comprimise. We could make the R,G,B separate floats into a
symbol for the data structures, like:
r1g1b1, r0.53234g0.0123b1.0, r0g0b0
.hc
If you are not part of the solution, you are part of the problem.
-
Eldridge Cleaver