Grass GUI (was Re: [GRASS5] Problems with vector import, and a suggestion)

[Glynn Clements]

Carl Worth wrote:

> > Translucency is awkward. Many display systems don't support it
> > directly. PostScript *can't* support actual translucency, as the
> > framebuffer is write-only; although you can provide some form of
> > emulation with halftones, you need to be careful when dealing with
> > multiple layers.
> 
> *sigh*. In my book, this is a strong vote against the choice of
> PostScript as a display technology then. Translucency is a very
> compelling feature, (and it does not demand too much of the display
> system -- nothing more than the ability to read the current state).

I didn't say that you can't do it; I said that you have to be careful
about what halftone patterns you use and how they're aligned. 
Basically, this means that you get better results if you take it into
account what's coming next.

Also, you can't avoid the issue when it comes to producing hardcopy. 
Of course, you could always compose the layers in software, but then
you either have to generate a 300+ dpi image, or choose a resolution
below the printer's capability.

For purely electronic output (e.g. image files), you may be better of
just generating individual layers and composing them with image
processing tools (e.g. ppmmix).

> > As for new features generally, they would belong in the general
> > display architecture, where they are available to all programs. Adding
> > functionality which is only available through an interactive
> > application is bad idea.
> 
> I agree. The real question is where does state go? What would you
> recommend as a mechanism for efficiently implementing layers for
> example? I know the current GRASS monitor redraw system is a hack, but
> where does the layer state belong? If the monitor is to operate
> efficiently, much of the rendering result needs to be cached
> somewhere.

The simple solution is to simply keep a list of commands, and run
through the list to perform a redraw. The more efficient solution is
to use the PNG driver to turn everything into images. In that regard,
a simple extension to allow e.g. d.erase to clear to transparent might
provide a significant benefit without requiring too much work.

>  > As for performance, the overhead of sending PostScript to an external
>  > process is trivial compared to the actual processing and rendering
>  > (which occurs regardless of whether the interpreter is external).
>  > Rendering complex geometry is expensive however you do it.
> 
> I have some particular interests regarding performance. I need to do
> some real-time visualization of dynamic geographical information
> (> 1 fps and the faster the better). And to make things even more
> interesting, I'm implementing this on handheld computers without
> hardware floating-point, (iPAQs running Linux). GRASS seems like a
> good fit for storing my geographical data. And I could easily pull off
> all of my real-time display requirements as long as I had efficient
> layer support.  For example, I'd like to render several raster and
> vector maps into the background layer, then loop over my dynamic data,
> (which is mostly just moving sites with changing attributes), erasing
> and drawing. I wouldn't mind having to take a hit in my frame rate for
> large-ish pan or zoom operations.

That could be implemented with R_panel_{save,restore}. These
operations could be made more efficient (e.g. by storing the data
either within the X server or in memory within XDRIVER) without any
changes to the protocol.

Unfortunately, there's always tension between performance and
flexibility. Specific applications with performance requirements might
be better served by a dedicated program. But that doesn't help the
rest of GRASS much.

Right now, I'm thinking mainly about being able to "leverage" what's
already there by making it easier to use.

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