[GRASS5] Re: 5.3 vs 5.7 disparity

[Hamish]

> > > > > > d.erase is now updated, including support for color=R:G:B.
> > > > > Should Derase() be changing the driver's colour table?
...
> Also, I've just noticed that it is reset to match the standard colour
> table by R_color_table_fixed(). Similarly, the hardware palette is
> similarly reset by R_color_table_float(). These two functions are used
> by d.colormode.
[...]
> comment in the d.colormode manpage:
> BUGS
>        It  is strongly recommended that the user erase the graph­
>        ics monitor screen (e.g., by running d.erase)  immediately
>        after changing the mode between fixed and float.

Shall we change d.colormode to do this automatically?
Or at least have it issue a warning?


> > > 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.
> > 
> > What I am concerned with is instead of resetting the 14th of 13
> > colors, as intended,
> 
> Actually, the standard colour table has 15 entries (0 to 14); I have
> no idea why, as only entries 1 to 13 are used, and there is no way for
> clients to modify entries.
> 
> > I've actually reset color 14 of say 256 or 65536,
> 
> Yep; although, that is better than resetting any of colours 1 to 13,
> given the behaviour of R_color_table_{fixed,float}, and the comment in
> the d.colormode manpage


So for picking an arbitrary number, maybe 14 and 15 aren't so bad after
all, as it may not be a good idea to assume the color table will be >256,
e.g. for use on a 4-bit display. Better not to use 255 anyway.

(15 is used when there are both custom foreground and background colors)

... I've got a 1-bit NCD X-terminal here (ncolors=2), and d.erase works 
correctly there: color=127:127:127 -> black, color=128:128:128 -> white.

Is the color table always going to be 256*256*256 long, or is it created 
at run-time based on the color depth with colors pulled from 0-1,0-1,0-1 
and translated on the fly?

shrug
I guess we should check for color blips on a smooth color transition
with d.legend or a map made with r.cost, but otherwise I guess I'll leave 
it as is.



Hamish