[GRASS5] Suggested color function names

Glynn Clements glynn at gclements.plus.com
Sun Apr 23 11:00:10 EDT 2006

Cedric Shock wrote:

> This has little to do with alpha support in the displays.  It has to do with 
> having a structure for colors. Hamish added one called RGBA_Color to gis.h. 
> These are just small changes to accommodate the color structure based on the 
> assumption that a color structure is a good idea. I'll take what you're 
> saying to mean that you don't like the name RGBA_Color for this structure or 
> the use of the letters RGBA in function names.  If you have a better name 
> suggestion that won't lead to confusion over the existence of alpha in 
> displays please share it with us.

I took the proposal of:

	int R_RGBA_color(RGBA_Color * color);
	int R_reset_RGBA_color(RGBA_Color * color, int);
	int R_reset_colors(int,int,RGBA_Color ** colors);

as implying that the alpha component would be used.

If that isn't the intention, I would change RGBA->RGB in the first two
function names. Also, add:

	typedef RGBA_Color RGB_Color;

and use RGB_Color for functions which ignore the alpha component.

Also, in the case of R_reset_colors(), you would need to either extend
the protocol to support interleaved data, or unpack the colours into
separate R/G/B arrays first.

In general, I'm against extending the protocol, or otherwise
attempting to enhance the existing display architecture. I want to
kill it off ASAP, and any enhancements will only make the task of
adding a backward compatibility layer to the new architecture harder.

BTW, I suggest removing the "set" field from the structure. Without
that field, the structure fits into 32 bits, and I suspect that most
functions would ignore that field anyhow.

In specific cases where you actually need a "set" field, you can use
a separate type, e.g.:

struct XRGBA_Color
	int set;
	RGBA_Color color;

Finally, I should mention that one of the reasons I'm against attempts
to "hack" alpha support into the architecture is that, so far as
possible, I would like the new architecture to support both video and
hardcopy output. And video-style alpha "blending" cannot be
implemented on hardcopy devices which typically only have one bit per
component. You can get a similar effect using halftones and
dither-masks, but the task is more complex than with video, and the
API needs to allow for that.

Glynn Clements <glynn at gclements.plus.com>

More information about the grass-dev mailing list