[GRASS-dev] New installation for wxPython GUI

[Glynn Clements]

Michael Barton wrote:

> Glynn should be almost done with his redo of the raster library that will
> let us send any d.* command to a PNG/PPM file without having to run d.mon.

It was "done" a while ago; I committed it to CVS as soon as the 6.1
branch was created.

All that remains is to fix bugs or implement wishes arising from
actually using the new functionality.

> This will be a significant change to the coding and a big improvement. Given
> that wxPython will accept graphic streams (one of it's big improvements over
> TclTk) I wonder if we should think about giving all the d.* commands the
> option outputting to a graphic stream (stdout??? Or some other pipe???) as
> well.

As it stands, the built-in driver can only write to a named file (and
you can't use /dev/stdout because it uses the extension to determine
whether to generate PNG or PPM/PGM output).

> For vectors, however, it seems like the best thing would be if d.vect could
> also output in a dxf-like format, that included a set of formatting strings
> (line width, color, etc) and label text, followed by a specifier of vector
> type (point, line, area) and cat number, and finally followed by a set of xy
> coordinate pairs for each  vector object.

Don't go there. The world doesn't need yet another homegrown vector
graphics format.

GRASS has already gone down this route once (the protocol between
libraster and the drivers), and it's the biggest single obstacle to
having decent graphics.

> This could then be picked up by a
> GUI to draw to screen rather than import as a raster image. You shouldn't
> have to worry about the vector database attributes because Trevor's v.what
> will find those simply by sending xy coordinates to the underlying vector
> file. Could something like this help with the digitizing? One thing about
> wxPython that concerns me in this respect (and something that was NOT a
> problem with TclTk) is that it doesn't seem to treat drawings to a device
> context as a vector object, but as  a raster. This is why I'm having trouble
> with the ugly zoom boxes. It's not easy to erase the box as its drawn
> without erasing the whole screen. Again, this  may be because I just don't
> know enough.

The Tcl/Tk canvas widget implements a "retained-mode" graphics system,
i.e. it maintains a set of objects which can be modified. Most normal
graphics APIs are "immediate-mode"; the functions simply draw
something to a "drawable" (either the visible screen or some
off-screen buffer).

Implementing "transient" graphics (zoom box etc) is best done by
performing all "persistent" rendering to an image, then handling
expose (redraw) events by drawing the rendered image then drawing any
transient graphics on top.

It's common for zoom boxes etc to be implemented using XOR plotting,
due to its self-inverse property (drawing the same thing again will
revert to the previous state). However, getting this right tends to
require operating at a relatively low level.

Under X, you would normally use a Pixmap for off-screen rendering
(rather than e.g. an XImage). A Pixmap is stored server-side (often in
off-screen memory on the graphics card), so drawing to a Pixmap will
use any hardware acceleration provided by the graphics card, and
copying the pixmap to the visible screen doesn't require the data to
flow between the client and the X server (if the Pixmap is stored on
the card, it doesn't need to travel between main memory and video
memory either).

Also, X allows a background Pixmap to be set for any window, as an
alternative to a background colour. This eliminates the need to
manually redraw the window in response to expose events; the X server
will automatically "clear" the window using the background pixmap.

> Many of the screen decorations (legend, scale, grid, etc.) currently done by
> d.*  commands should be done by the GUI probably. Or better yet, the d.*
> commands should again output text equivalents of what they are drawing that
> can be picked up by the GUI and drawn. For example, d.legend should output
> information about box size, colors of each legend object, text format, etc.
> 
> One thought that just came to me is that perhaps d.* commands should  also
> output what they do in ps.map format. This could either be run through
> ps.map or sent to a GUI.

The option of generating PostScript (or SVG, etc) output from the
display architecture is a long-term goal. In order for that to happen
in a useful way, the existing d.* modules need to be migrated to a
higher-level API (at a minimum, using D_* instead of R_*). The
pixel-oriented R_* API is unsuitable for generating PostScript (or
SVG, etc).

In turn, that may require some changes to the R_* API, and I don't
intend on making significant changes in that area while separate
display drivers (XDRIVER, PNG driver) are supported. Once the display
drivers have been made obsolete (which basically requires a GUI which
can be controlled from the command-line), changing the client-side API
will be a lot simpler.

For now, the most feasible strategy is to migrate d.* from the R_* API
to the D_* API, extending the latter where necessary by adding new
functions which can be implemented on top of the existing R_* API.
Once that's done, we can think about implementing the D_* API on top
of a decent graphics API such as PostScript or SVG.

-- 
Glynn Clements <glynn at gclements.plus.com>