[GRASS5] Re: 5.3 vs 5.7 disparity

Hamish hamish_nospam at yahoo.com
Mon Feb 2 00:43:55 EST 2004


> > > > 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..

[*] 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, but by the look of the comments in colors.h 
it would be ok -- and it seems to work ok...



----
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 and should 
probably be changed to something else anyway.
----


I'm happy to entertain better solutions, but AFAICT it works properly
now (including non-X drivers) and isn't evil.



?
Hamish




More information about the grass-dev mailing list