[GRASS5] R_color vs R_standard_color

GRASS GIS GRASS GIS developer
1

Hello,

Is there any real difference between R_color and R_standard_color?

Take this example (d.bargraph's background color):

int color1;
const int customBGcolor = MAXCOLORS + 2;

...

Then either

R_reset_color(customBGcolor, R, G, B);
color1 = customBGcolor;

or (essentially)

color1 = D_translate_color (...);

happens. So now color1 is either a number on the range 1 to MAXCOLORS if the
color came from translate_color, or it's MAXCOLORS + 2 if a color was
provided and set. Later, when drawing the box, the following is done:

if(color1 > MAXCOLORS) /* ie custom RGB color */
    R_color(color1);
else
    R_standard_color(color1);

Is this because:

a.) colors and standard colors really are completely separate but both are
being handled using a single integer with a divided range than a struct.

b.) In the past they were different but now they are the same.

c.) Something else I'm failing to imagine.

Thanks,

--Cedric

2

Cedric Shock wrote:

Is there any real difference between R_color and R_standard_color?

I made an attempt at documenting all of the different colour systems
in display/drivers/lib/colors.txt.

The colour table used by R_color() can be modified through
R_reset_color[s], while the one used by R_standard_color can't.

Take this example (d.bargraph's background color):

int color1;
const int customBGcolor = MAXCOLORS + 2;

...

Then either

R_reset_color(customBGcolor, R, G, B);
color1 = customBGcolor;

or (essentially)

color1 = D_translate_color (...);

happens. So now color1 is either a number on the range 1 to MAXCOLORS if the
color came from translate_color, or it's MAXCOLORS + 2 if a color was
provided and set. Later, when drawing the box, the following is done:

if(color1 > MAXCOLORS) /* ie custom RGB color */
    R_color(color1);
else
    R_standard_color(color1);

Is this because:

a.) colors and standard colors really are completely separate but both are
being handled using a single integer with a divided range than a struct.

b.) In the past they were different but now they are the same.

c.) Something else I'm failing to imagine.

Most of the complications arise from the fact that the display
architecture originally only supported colour-mapped displays, and
R_reset_color[s] modified the palette directly. Support for RGB
displays was added later, by providing a software palette.

The point of having a set of standard colours was to provide a common
palette so that you could overlay multiple maps in the monitor without
conflicts over palette entries.

--
Glynn Clements <glynn@gclements.plus.com>

3

On Tue, Apr 18, 2006 at 09:58:44AM +0100, Glynn Clements wrote:

Cedric Shock wrote:
> Is there any real difference between R_color and R_standard_color?

I made an attempt at documenting all of the different colour systems
in display/drivers/lib/colors.txt.

(Un)related:
Let me suggest to write GRASS documentation on doxygen style
whenever possible and appropriate. Programmer's manual is
auto-generated from that and will not include .txt files.
We only get more programmers if the software is documented.

thanks

Markus

4

Is there any real difference between R_color and R_standard_color?

Take this example (d.bargraph's background color):

Again, most of the RGB settings from color= options in the modules was
added by me not too long ago as minimally invasive bolt on hacks and you
shouldn't read too much into it. i.e. to avoid having to redo all the fn
prototypes when the draw command is done in a function via passed
variables, as the color table is "global". No other great logic behind
doing it this way and probably not how you'd do it if RGB support was
there from the beginning. It would have been better to have a RGBCOLOR
struct from day one, as would having your current cleanups at that time.
But as it was I worked within the existing framework. As I went through
the modules the method improved slightly, and used what seemed
appropriate for each module, which confuses things a bit more.

int color1;
const int customBGcolor = MAXCOLORS + 2;

...

Then either

R_reset_color(customBGcolor, R, G, B);
color1 = customBGcolor;

or (essentially)

color1 = D_translate_color (...);

happens. So now color1 is either a number on the range 1 to MAXCOLORS
if the color came from translate_color, or it's MAXCOLORS + 2 if a
color was provided and set. Later, when drawing the box, the
following is done:

if(color1 > MAXCOLORS) /* ie custom RGB color */
    R_color(color1);
else
    R_standard_color(color1);

Is this because:

a.) colors and standard colors really are completely separate but both
are being handled using a single integer with a divided range than a
struct.

b.) In the past they were different but now they are the same.

c.) Something else I'm failing to imagine.

d) as above. I considered 0 to MAXCOLORS to be standard, anything above
that to be a C legal sandbox.

At the time it worked and didn't break anything. The "global" aspect
of the color table lead to simple patches, which I liked.

Note I never updated d.legend to allow color=RRR:GGG:BBB, as that would
cause problems in the scale. I'd urge you to look at it and understand
why. (d.legend may be a bit of a nightmare for someone who likes
breaking things up into smaller functions :wink: but I'm happy with it,
fragile as it might be.)

Hamish