[GRASS5] Grass GUI

[Carl Worth]

On Feb 7, Glynn Clements wrote:
 > Carl Worth wrote:
 > I discuss some of the specifics below, but I'd caution against
 > extending the monitor protocol unless you can get a lot of benifit
 > from a small change.

The current 13-color fixed palette for drawing commands is extremely
limiting. IMHO, extending that to arbitrary RGB colors would be a lot
of benefit from a small change. Similarly for line styles, (which
nearly all display types support to some extent natively), and more
generalized sites rendering than the current 5 fixed shapes, (why not
support a scaled and rotated vector map for rendering on sites as well
as pixmaps).

 > Bear in mind that the underlying architecture is far from ideal. It's
 > future probably involves being thrown away and replaced with something
 > completely different, rather than incremental improvement.

I'd be open to that too. Bear in mind, I'm not throwing out lots of
feature requests here hoping someone will do it. I'm planning on
dedicating a lot of full-time effort to improve GRASS, (primarily in
terms of display and user-interface --- it already has a tremendous
amount of capability "under the hood" and far beyond my expertise).

 > > How can we efficiently manage map symbols, (ie. pixmaps), with a
 > > stateless monitor and protocol? The same question applies, (to a
 > > lesser extent to passing colors
 > 
 > The monitor isn't stateless. 

I guess I was referring to the monitor as "stateless" in terms of your
recent post suggesting the monitor should remain a "dumb" display
device that ideally knew nothing about GRASS.

The question is how to efficiently reduce repeatedly rendering
redundant information, (eg. drawing hundreds of identical sites all
over a map). This gets a bit complicated in that the sending side of
the protocol might be many d.* display commands, (meaning separate
invocations with no shared state between them). So, it's probably fair
to say that caching belongs on the other end of the protocol,
(whether in the monitor or in a new stateful object that gets inserted
between the receiving end of the pipe and the monitor I don't know).

 > > How hard would it be to extend raster maps to 4 channels? (RGB +
 > > alpha).
 > 
 > Raster maps are single channel, and are likely to stay that way
 > forever. Colour images are best handled as separate R/G/B layers;

That's fine. Adding a new alpha layer is then quite easy in this
respect.

 > The issue is what's involved in implementing a "d.rgba" program (i.e. 
 > d.rgb + alpha), which translates to what's involved in extending the
 > display protocol to support alpha information.

exactly.

 > The first issue is that it is impossible to perform translucent
 > rendering on write-only devices. This includes all PostScript
 > devices;

I'm confused Glynn. There is currently no PostScript display driver
is there? (I see cell, png, htmlmap, and xdriver in my docs). And even
if one were created, it would still be possible to do composition of
translucent layers prior to outputting the postscript would it not?

In any case, I am personally very interested in translucent rendering
and am willing to do the work to make it possible.

 > > I can't imagine any mechanism for getting at something like that
 > > in a cross-platform toolkit. Ideas?
 > 
 > I'm fairly sure that you can get at toolkit-specific information.

Thanks. I'll look deeper.

-Carl

-- 
Carl Worth                                        
USC Information Sciences Institute                 cworth at east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203		  703-812-3725