[GRASS5] [cworth@east.isi.edu: GRASS on iPAQ]

[Glynn Clements]

Markus Neteler wrote:

> However, I have been doing quite a bit of work on a new vector-based
> drawing engine for X which uses the Render extension. This new library,
> (Xr), supports wide lines and splines, (all the common join, cap, and
> dash styles), with anti-aliased edges. All shapes can be drawn
> translucently as well. The Xr drawing API is quite easy to use, (it's
> similar to PostScript). So, I do think that Xr might be very useful as
> the backend for X-based drawing in GRASS instead of the old core Xlib
> drawing routines. (There's even a layer under Xr called Xc that will
> eventually support all of the rendering on the client side so that Xr
> will be usable even on X servers without the Render extension).
> 
> Xr is still in progress. The code is in the CVS server pointed to at
> http://www.keithp.com, but there is not much documentation yet. It
> will probably be documented and quite ready to use early next year, so
> maybe in time for GRASS 5.1.

1. I would only consider it ready to use when either Xr is ubiquitous
or Xc is available. Making GRASS unusable on systems which don't
support the Render extension is out of the question, IMHO.

2. We also need to allow for Windows. Either Xc needs to work there,
or we would need to find equivalent native functionality.

3. We also need to allow for non-screen output, i.e. the PNG and CELL
drivers.

4. For the future, I would like to also allow hardcopy output in a
compatible manner. That would impose some significant constraints,
primarily:

a) the architecture has to scale to much higher spatial resolutions
than are typical for screen display.

b) OTOH, printers typically have low colour resolution (i.e. 1 bit per
component), and rely upon dithering.

c) A printer's framebuffer is often write-only, which precludes
read-modify-write operations such as alpha-blending, and XOR plotting.

> Do keep up the great work. I'll definitely check back on GRASS in the
> future.
> 
> -Carl Worth
> 
> PS. I'll mention here some of the specific frustrations I ran into
> with GRASS. These are intended not as complaints, but as things to
> keep in mind while redesigning things for 5.1 and beyond. As I
> mentioned, some of these are due to the fact that GRASS just wasn't
> designed to do some of the things that I wanted, (although there's no
> reason a future version couldn't be).
> 
> 1) The drawing support was quite limited, (things like fixed palette
>    of colors, fixed line width, fixed line style, fixed set of
>    possible icons, etc.)
> 
> 2) The drawing support was often too slow for the things I needed. I
>    was stressing GRASS out pretty hard since I was trying to do some
>    animation of real-time data, (about 1 frame per second), on top of
>    some large raster data sets. On top of that, I wanted this to work
>    on a handheld computer with no floating-point unit. The need to
>    continuously rescale the background for a simple pan or a local
>    modification of some higher layer made things infeasible.

The existing display architecture just isn't suited to real-time
applications. Furthermore, imposing a real-time requirement on a
future display architecture could create significant complications. 
The main issue is that increasing functionality eliminates the
possibility of supporting environments which can't implement it.

> 3) I overcame both problems to some extent by using the XDRIVER_WINDOW
>    hack to get at the window ID of the GRASS window. Then, since GRASS
>    uses a backing pixmap for all of its drawing, I actually was able
>    to erase/redraw my graphics on top of background maps without GRASS
>    needing to rescale/redraw things. Plus, I also got to do my own
>    drawing, so I could do interesting things including drawing
>    translucent regions, etc.
> 
>    Allowing a custom program to draw on top of graphics from GRASS is
>    actually a powerful idea, (although the current XDRIVER_WINDOW
>    support is really just a hack that hints at the idea).
> 
>    With that I was able to make an image such as:
> 
> 	http://dsn.east.isi.edu/grass/spesutie_translucent.jpg
> 
>    In which GRASS is only drawing the background raster layer, and I
>    was manually drawing everything on top. If GRASS could have
>    supported drawing like that, (bitmapped icons, translucent
>    polygons, TrueType fonts, etc.), that would be quite nice.

Any display architecture will have limitations, and there will always
be potential applications which exceed those limitations. In which
case, the only solution is for the application to bypass the display
architecture and do it itself.

> 4) Another problem came up when I was doing the drawing via
>    XDRIVER_WINDOW. I needed to map geographical coordinates to screen
>    coordinates. GRASS has code to do this of course, but it is
>    implemented via static variables. This only works because GRASS is
>    primarily standalone programs, each of which starts up, sets the
>    variables, performs some computation/drawing, then exits. The
>    problem comes in a program such as mine that starts up and
>    continues to run even after an intervening d.zoom for example. When
>    that happens, the static variables used by the functions called in
>    my program continue to have the old values, so the mapping is
>    totally broken. I had to go to considerable effort to keep my
>    drawing in synch. And even then it only works if the pan is done
>    from within my program so that it nows to re-calculate the
>    variables. I still lose if an external d.zoom is run, (since my
>    program doesn't know the mapping parameters are stale). All of this
>    should be cleanly handled within the GRASS library.

Are you asking for some kind of event/callback mechanism, or just a
simpler way to check if the region has changed and/or update it?

> 5) Finally, I was repeatedly frustrated by only being able to run more
>    than one GRASS session at a time. I know that GRASS doesn't yet
>    have all of the fine-grained locking that it really needs. But even
>    so, it is quite frustrating that it would not let me run multiple
>    sessions in different locations simultaneously, (unless I ran them
>    as a different user).

The current startup isn't that hard to bypass. The main complication
is that monitor names (x0, x1, ...) are per-user, not per-session.

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