[GRASS-dev] Re: GRASS 7 status overview

Glynn Clements glynn at gclements.plus.com
Mon Feb 15 05:26:54 EST 2010


Hamish wrote:

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

This is problematic, as the file can be modified without the timestamp
changing (the timestamp is typically only accurate to 1 second). It
can be done, but the logic is non-trivial (and it would still need to
poll the timestamps continually).

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

You can use percent=0, in which case it will only update when it
receives SIGUSR1 (that doesn't work on Windows; suggestions?).

You can use e.g.

	GRASS_NOTIFY="killall -USR1 `pidof wximgview`"

to cause SIGUSR1 to be sent whenever a module calls D_close_driver().

OTOH, if the issue is X bandwidth rather than application CPU usage,
it would be possible to add an option to only perform a redraw if the
data changes.

BTW, there is also the wxpyimgview script, which is the same thing but
written in Python rather than C++. It didn't occur to me to use Python
until shortly after I'd finished writing wximgview. The original
reason for using C++ was that I assumed that I would have to perform
the RGBA->RGB conversion in Python, which would be insanely slow; then
I realised that I could use NumPy.

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


More information about the grass-dev mailing list