[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