[GRASS5] Grass GUI

[Glynn Clements]

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

At the code level, you can use other colours for drawing; you just
have to define them with R_reset_color(), then use R_color() instead
of R_standard_color(). I'm told that the documentation isn't
particularly clear on this, though.

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

Line styles (dash patterns) alone shouldn't present too much of a
problem.

Line thickness is more complex. Some application code assumes that a
line is one pixel wide (e.g. the raster drawing code used to fill
areas of constant colour by drawing horizontal lines; I changed it to
use 1-pixel high rectangles). Also, different graphics APIs may have
different semantics when dealing with line styles and "wide" lines
(e.g. for a dashed line with rounded caps, is each dash rounded?).

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

Right; my point is that it's not worth doing too much work on a
graphics architecture whose days are numbered. But 5.0 is going to
have to either use the existing architecture or be postponed
indefinitely.

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

No, but I'm thinking about the future.

The way I see it, 5.0 gets released with (more or less) the existing
display architecture. Once that's done, a new display architecture can
be created, starting with a blank slate.

I would very much hope that any future architecture would support
screen display, image creation and printing, and that it would do a
reasonably good job of all of them, in spite of their differences. It
would be less than ideal if translucency was implemented in a way that
didn't work well for printing.

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

Consider the case where you wish to overlay translucent vector area
(filled polygon) maps on an opaque raster background. If you simply
composite the layers into a raster, then convert that to PostScript,
you either have chunky pixels or a massive PostScript file.

This is basically the reason why I didn't write a PostScript driver. 
The current display architecture is far too oriented towards pixels. 

Any vectors would have to have been rasterised at the same resolution
as bitmaps (which are scaled to the display resolution by the client),
otherwise the results wouldn't "line up". So, you may as well just use
the PNG driver, and convert the resulting image.

A *worthwhile* PostScript driver would draw rasters at their source
resolution (typically much lower than the printer's resolution), but
vectors and text at the printer's resolution.

-- 
Glynn Clements <glynn.clements at virgin.net>