[GRASS5] [bug #1759] (grass) d.what.sites: very slow over a network connection

this bug's URL: http://intevation.de/rt/webrt?serial_num=1759

Request number 1759 was commented on by 'hbowman' (Harmisch Bowman).
Responding to this message will send mail to the requestor.
      
      Request Tracker
      rt@intevation.de

--------------------------------------------------------------
Cc: grass5@grass.itc.it

Hi,

GRASS 5.3/HEAD (Nov 2003)

Using the non-5.0.x d.what.sites over a 10Mbit ssh connection down the hall is
very slow & uses a ton of bandwidth during the "vector blink" stage. The
cursor doesn't return to crosshairs for several seconds, to the point where it
is unusable. (sites file contains a total of 4 sites)

see also:
http://article.gmane.org/gmane.comp.gis.grass.devel/1380

blame:
R_panel_save() & R_panel_restore() sending xwd over the X connection, followed
by a disk write to a temporary file.

but what can be done to fix the problem? The current situation sucks.
Would Carl Worth's driver fix this? Figure out how not to use XGetImage() and
XPutImage()?

'd.barscale -m' seems to work ok without such issues..?

[also, cosmetically, I'd think you'd want a -v:verbose flag not a -q:quiet
flag to show / suppress debug info. And the -q flag should suppress the
"loading sites@mapset...NDIM=2, RTYPE = 0, NSTR=5, NDEC=0"
text as well.. I can make the change if people agree, or not if they don't.
noisiest wins.]

Hamish

-------------------------------------------- Managed by Request Tracker

Harmisch Bowman via RT wrote:

Using the non-5.0.x d.what.sites over a 10Mbit ssh connection down the hall is
very slow & uses a ton of bandwidth during the "vector blink" stage. The
cursor doesn't return to crosshairs for several seconds, to the point where it
is unusable. (sites file contains a total of 4 sites)

see also:
http://article.gmane.org/gmane.comp.gis.grass.devel/1380

blame:
R_panel_save() & R_panel_restore() sending xwd over the X connection, followed
by a disk write to a temporary file.

but what can be done to fix the problem?

Simply revert the changes. The driver architecture wasn't designed to
do this sort of thing.

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