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@virgin.net>
- see attachment.