[GRASS5] Re: 5.3 vs 5.7 disparity

[Glynn Clements]

Hamish wrote:

> > > > > use of DEFAULT_FG_COLOR/DEFAULT_BG_COLOR for G5.7 compliance
> > > > 
> > > > 1. Neither XDRIVER nor d.erase use these macros. d.erase could be
> > > > changed easily enough,
> ...
> > > d.erase is now updated, including support for color=R:G:B.
> > 
> > Should Derase() be changing the driver's colour table?
> 
> Well, it isn't ideal, but I don't think it hurts anything. The part of
> the table[*] that is modified is off the end of the chart (MAXCOLORS + 1)
> ..thus ~extending the color table more than "changing" it. If
> something unrelated is calling that color number, it would be a bug
> anyway..

I think that you are confusing the two colour tables.

The standard colour table is initialised to the colours specified in
color.h, and cannot be changed. R_standard_color() selects a colour
from the standard colour table.

The other colour table is also initialised to the same set of colours. 
However, the entries may be changed using R_reset_color() and
R_reset_colors(). R_color() selects colours from this table, as do the
R_raster* functions.

Note: on indexed-colour displays, the driver can be put into
"floating" colour mode (e.g. with "d.colormode float"). In that
situation, the colour table is effectively the hardware palette.

These settings persist, so one client may set the colour table, while
another client uses it. Having said that:

1. The d.* programs normally explicitly set any colours which they
will be using, so the prior state of the colour table is irrelevant in
those cases.

2. While there may be cases where the colour table is required to
remain unchanged between commands, it seems unlikely that it would be
necessary for the colour table to remain unchanged by Derase(). I
would assume that a sequence of "erase, set colour table, draw" would
be more likely than "set colour table, erase, draw".

IOW, the change is probably safe, although it isn't a foregone
conclusion.

> [*] here I mean the GRASS standard colors' table, not anything a driver 
> uses.
> 
> src/include/colors.h seems extensible; I don't see anything that uses
> MAXCOLORS to set the size of a memory array or anything.
> 
> That's not to say something funky won't go on after you call
> R_reset_color(), I don't really understand the translation to the
> drivers' color tables,

That's OK; the process is rather convoluted. I generally need to
refresh my memory whenever I do anything in that area.

> NB:
> raster/r.out.png/pngfunc.h  redefines it to 256 for no apparent reason.
> 
> src.contrib/CERL/SGI/panel/9.6/src/D.apps/cam.c  redefines it to 4096, 
> then uses that for an alloc().
> 
> src.contrib/CERL/SGI/panel/9.6/src/D.apps/ep.c  ditto.
> 
> src.contrib/GMSL/g3d/src3d/raster/r3.showdspf.openGL/togif.c  =>
> int[256].
> 
> 
> but in those four cases MAXCOLORS isn't colors.h's one

If they don't use colors.h, they aren't actually *redefining* it; it's
just defining another macro which happens to have the same name. 
MAXCOLORS is a fairly generic name; I doubt that the authors of those
programs were even aware of the MAXCOLORS in colors.h.

> and should probably be changed to something else anyway.

If anything, colors.h should change. The more widely-used a header is,
the greater the obligation for it not to use "common" names,
especially for preprocessor macros.

That applies even more to the colour names (RED, BLUE etc), and
especially to FLOAT. [I'm wondering if AQUA could eventually cause
problems on a Mac.]

-- 
Glynn Clements <glynn.clements at virgin.net>