[GRASS-dev] Re: GRASS 7 status overview

[Hamish]

Michael:
> > OK wximgview works. [...] So it's to
> > offer a way to view graphics created by d.* commands?

Glynn:
> Yes. Specifically, it continually refreshes the display from the
> contents of the image file (which must be written using
> GRASS_PNG_MAPPED=TRUE, so that the file is modified in place, never
> truncated), providing a rough substitute for XDRIVER (i.e. run d.*
> commands from the command line, observe the result in a window).

would it be possible to have it watch the file's timestamps and only
refresh if it sees that the file has been changed?

Besides the raw d.* on the command line use, a common use of a super-light
weight GUI for me is for running grass via tunneled ssh+X. At work this
is just to the number cruncher down the hall from my desktop P4, but if
I'm running a big job I might leave a GNU Screen session running overnight
and it is nice to be able to ssh from home, quickly check the status and
display results, and then launch the next run. With d.mon this works
beautifully. It's actually quite usable over our really crappy ADSL.
(PNG driver + `qiv -e file.ppm` then click or mouse-wheel to refresh
works really well.  the wxgui is unusable over that connection, I
suspect the tcltk GUI could be usable)


With continual refresh I worry that ximgview and wximgview will not be
much use ssh'ed from the near-dialup connection speeds from home.

with percent=10 gkrellm is showing it using about 1.4Mbit down the hall
over our building's 100mbit ethernet, with percent=1 that falls away, but
the lag time from command to render is about 10 seconds.
A cpu limit set to 1% (integer only) probably is going to be too high
for dial up, but any less would create unacceptable lag times.
?


Hamish