XDRIVER

[Raymond Venneker]

gardels at ced.berkeley.edu (Kenn Gardels) writes on Thu, 7 Oct 1993

> True 24-bit capability is in the development pipeline.

Could we have some more information on this?

-------
Fri, 8 Oct 1993 12:42:13 -0700 (PDT), Mark P. Line wrote:

> Does anybody know what the reasoning was behind this particular design in
> GRASS? It would seem to me that if you can have forty-eleven categories in
> a raster map, you should be able to have forty-eleven colors also.

I know a little bit about the graphics system because I broke my head
some 5 years ago debugging the suncore driver supplied with GRASS 2.0
(yes, two-dot-zero). At that time GRASS only ran on Sun (using 8 bit
colours) and Masscomp (10 or 12 bit colours).
I start talking from memory now, correct me if I'm wrong:

On the client side (d.*) two C libraries are placed on top of
eachother, displaylib and rasterlib (I never understood why there
are two, but there may be good reasons).  In GRASS 2.0 there were
two communication mechanisms:  sockets for BSD (Sun) and fifo's
for SYSV (Masscomp). The sockets were removed later.  If I recall
correctly, the functions in rasterlib, the communication protocol,
and the driver functions are modelled after the calls in the old
(Sun) SUNCORE display library. So the suncore driver did very
little, the masscomp driver called GKS routines.  The drivers used
the full screen as their display window (GRASS ran from a separate
tty) and did their own subwindow management. Today, we know these
subwindows as frames.  (Perhaps this proprietary subwindow handling
may be another cause for slight performance decrease.) From GRASS
3.0 or so, another C library was added on the client side: Dlib.
This contains functions like Dcell(), Dvect(), etc. which call the
series of functions in the other libraries needed for map display.
The drivers added later, like the X driver, are still based on this
mechanism.  In fact, there's been _little_ change in the whole system
which is probably the main reason for slooooowness.  I think the
X driver is really a `solution' not designed to make use of
sophisticated X features for the sake of compatibility.

My personal opinion is that the whole thing needs a thorough revamp

Raymond [follow-ups on grassp-list please]