[GRASS5] Suggested color function names

Hamish hamish_nospam at yahoo.com
Sat Apr 22 11:22:46 EDT 2006


> > Alpha support in the current display architecture isn't going to
> > happen (I reverted the last attempt to add it, and will do likewise
> > in future). The core X API doesn't support it, and hacking it in is
> > grossly inefficient (read-modify-write cycles aren't practical on a
> > remote display).
> >
> > Developers' time would be better spent replacing the modules which
> > are tied to the current architecture so that it can be discarded in
> > favour of a from-scratch replacement.
> >
> > I'm referring to anything which uses R_get_location_with_*,
> > primarily v.digit and i.points.
>
> 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.


gis.h has nothing to do with display drivers or raster graphics
limitations, the RGBA_Color type is just for passing stuff around
regardless of GUI a, GUI b, GUI c, or none. Having alpha in there might
be useful for a future GUI "d" or simply if for some reason you want to
have a GRASSRGB and ALPHA columns in a vector attribute table and
push them around in your module. I don't really know for what it will
be used but I don't want it to be a limiting factor in the future 
either. My hope is that the "from-scratch replacement", when it happens,
can use it right way without modification or a dupe version of almost
the same thing, without compromise.

Plus we can put a "support for 32-bit color" bullet on the box now. :)

I can see the point that is that it is perhaps misleading to future
coders to start (at least tacitly) adding R_(r,g,b,a) fns or have a
system which is made up of even more patchwork of many differnt ideas.


Hamish




More information about the grass-dev mailing list