[GRASS5] Color code cleanup

[Cedric Shock]

On Tuesday 18 April 2006 02:12, you wrote:

> (As I'm sure you've found)
> When I added RGB support to a bunch the display modules using
> MAXCOLORS+1 type tricks I considered it a bit of an ugly hack and it was
> done a little differently for each module. This was partially to get
> around the fact that gis.h doesn't have a RGBCOLOR struct in it.
> (e.g. SYMBCOLOR in symbol.h)
>
>
> I'd have such a creature as so:
>
> (in gis.h)
>
> typedef struct {
>     int set;  /* 0 unset, 1 set, -1 "none" */
>     unsigned char r, g, b;
> } RGBCOLOR;
>

Why do we need to keep track of set information? Since structs are sometimes 
but not consistently initialized to zeros by compilers this seems like an 
easy way to make bugs that are very difficult to track down.

This is everything I can think of that could go in a color:

typedef struct {
    int standard;  /* Positive integer if this is a standard color, 0 
otherwise*/
    unsigned char r, g, b, a; /* red, green, blue, and alpha */
    float fr, fg, fb, fa; /* This is twice as big as everything else combined 
*/
} RGBA_COLOR;

None can simply be alpha==0. An easy way to check this is just:

if (color.a) {
	do something
}

I think the floats should probably go. We might want some shared structure for 
them, but it'd be separate anyway.

Display code might want to tack on another indexed color for the non-standard 
color table. This does avoid lookup of RGB value in a table on an indexed 
display, right? Setting colors seems to be being done fairly infrequently so 
this probably isn't a big performance concern.

Is there any R_ protocol command for none. Something that just turns off 
drawing until another color gets set?

--Cedric