[GRASS5] Grass GUI

[Glynn Clements]

Carl Worth wrote:

>  > A short list of what I'm dreaming of as a display tool :
>  > + manage layers (add, remove, re-order)
>  > + save/load "view" created (list of layer, legend and extent)
>  > + enhanced drawing capabilities:
>  >   - color transparency for raster,
>  >   - style for lines (including parallel lines for roads)
>  >   - fill area with color or patterns, and transparency
>  >   - style for sites (pixmap or vectorized symbols, the later being orientable)
>  > + view created usable in the map manager for output
>  > + query on the map (raster and vector) and (eventually with an
>  >   external function) manage the attribute of selected object(s)
>  > + mesure on the image
>  > + draw line on it and pass it to external application (profil in a DEM,...)
>  > + at a second time, add point/line area digitizing
>  > + map manager must work with mouse, but let you fix all positions or
>  >   dimensions with figure (this ensures a perfect map)
> 
> This looks like a pretty good list to start with, (although not all of
> those features must be "builtin" to the GUI -- several will work just
> fine as external programs called by the GUI).
> 
> I've been needing a nice GUI for a while, and fortunately just wrapped
> up some other projects here, so I should be able to dedicate myself to
> GRASS GUI development.
> 
> One of the first things I would like to do is to enhance the driver
> protocol as needed for the "enhanced drawing capabilities" you
> suggested above, (including arbitrary RGBA colors for all drawing
> operations). And for that I have a couple of questions:

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.

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.

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

> 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;
quantisation degrades colour resolution, and results in raster layers
which are largely useless for anything other than rendering (because
the resulting categories have no significance beyond their colour).

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.

The first issue is that it is impossible to perform translucent
rendering on write-only devices. This includes all PostScript devices;
on many (most?) laser printers, the framebuffer is physically
write-only (i.e. the framebuffer RAM's data-in lines connect to the
CPU, while the data-out lines connect to the print engine).

You can obtain a similar effect with halftones, but you need to be
careful when handling multiple layers. If you draw two halftoned
layers with the same halftone offsets, the first one is completely
overwritten by the first. If you draw enough halftoned layers, the
original layers are eventually obscured completely.

In short, don't assume that it's just a matter of blending each layer
with the output so far using linear interpolation. It helps if you
know at the start how many translucent layers are involved, along with
the alpha factors.

Personally I feel that, compared to translucency, there are other
things which would be significantly more useful and also less work
(adding something as significant as translucency to the display
architecture would kick the 5.0 release into the long grass).

E.g. a simple display layer manager would leverage what already exists
in terms of src/display/d.*, without introducing any system-wide
complications.

> As far as toolkits go, I'm a big fan of X, especially some of the
> recent features in X such as the Xft support and the RENDER extension,
> (which allows for translucent image composition). So, I'm competent
> and happy to code the necessary driver pieces in Xlib.

Don't overlook the significance of the term "extension". Core
functionality should work on any X server. 

> As for the rest of the GUI, I'd be willing to look at wxWindows,
> (although it might be hard to get at the resource needed for the
> XDRIVER_WINDOW variable. I assume I need to set that to the XID of the
> window of interest, no? 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.

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