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

[Carl Worth]

On Feb 7, Glynn Clements 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).

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

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

The other thing that's missing is database locking at a
finer-level. The current user-level lock is extremely coarse, (and
frustrating), and doesn't solve the problem I have a one process
updating site information while another one sits in a display
loop. But, granted, I am probably going in directions with GRASS that
it was never designed to go --- but no reason it can't be fixed to get
me there either. ;-)

-Carl

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