Details Ticket 1759


Comment | Reply | Take | Resolve


Serial Number 1759
Subject d.what.sites slow and possibly wrong output
Area bug
Queue grass
Requestors paul-grass@stjohnspoint.co.uk
Owner none
Status open
Last User Contact Mon Nov 17 15:16:35 2003 (5 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Mon Nov 17 15:16:35 2003 (5 yr ago)
Created Mon Mar 24 17:25:07 2003 (5 yr ago)

Transaction History Ticket 1759


Mon, Mar 24 2003 17:25:07    Request created by guest  
Subject: d.what.sites slow and possibly wrong output

Platform: Irix
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: Latest CVS

The latest CVS version of d.what.sites seems to give some strange output:

"+" at 352786.7768595(E) 336373.55371901(N)
gpsheights in PERMANENT  352785.935|336372.876 1813  15.334 0.0111
  Distance from "+":268765336.00
  25inspot in PERMANENT  352792.5360959|336371.4729453 18
  Distance from "+":268701408.00
                    ^^^^^^^^^^^^
                      This number seems very big? Or else its meaning is unclear.
It's also noticeably slower, e.g. half a second delay between the results for
each sites layer displayed appearing, on the slow old machine I'm using at the
minute.

Paul
Mon, Mar 24 2003 20:24:36    Mail sent by glynn.clements@virgin.net  
Return-Path <glynn.clements@virgin.net>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn.clements@virgin.net>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <15999.23061.677960.709420@cerise.nosuchdomain.co.uk>
Date Mon, 24 Mar 2003 19:18:45 +0000
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #1759] (grass) d.what.sites slow and possibly wrong output
In-Reply-To <20030324162508.8BFE713B4A@lists.intevation.de>
References <20030324162508.8BFE713B4A@lists.intevation.de>
X-Mailer VM 7.07 under 21.4 (patch 12) "Portable Code" XEmacs Lucid
X-Spam-Status No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03 version=2.43
X-Spam-Level
Request Tracker wrote:

> Subject: d.what.sites slow and possibly wrong output
> 
> Platform: Irix
> grass obtained from: CVS
> grass binary for platform: Compiled from Sources
> GRASS Version: Latest CVS
> 
> The latest CVS version of d.what.sites seems to give some strange output:
> 
> "+" at 352786.7768595(E) 336373.55371901(N)
> gpsheights in PERMANENT  352785.935|336372.876 1813  15.334 0.0111
>   Distance from "+":268765336.00
>   25inspot in PERMANENT  352792.5360959|336371.4729453 18
>   Distance from "+":268701408.00
>                     ^^^^^^^^^^^^
> 
>                       This number seems very big? Or else its meaning
>                       is unclear.

The number should be the distance between the location of the click
and the nearest site. FWIW, I get sensible results on Linux/x86 with
the spearfish dataset.

I can't see any obvious portability issues; I suspect that you will
need to use a debugger to determine why it doesn't work for you.

> It's also noticeably slower, e.g. half a second delay between the
> results for each sites layer displayed appearing, on the slow old
> machine I'm using at the minute.

Looking at what's been added, the changes consist mostly of graphical
operations. 

1. There are 8 calls to R_flush() per click; if this call is slow,
either because XClearWindow() (which basically copies the frame-buffer
pixmap to the screen) is slow or there's significant lag in the
communication link, then that would explain it.

2. The frame-buffer pixmap is read from the X server and saved to a
temp file (by R_panel_save()) before each click, and restored from the
file afterwards. This will be slow if the X connection is slow,
particularly if the window is large and/or has a high bit depth.

IMHO, the animation feature is a gimmick, and should be scrapped. The
GRASS graphics API isn't SDL; it wasn't designed for this sort of
thing.

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


Tue, Mar 25 2003 15:45:11    Mail sent by paul-grass@stjohnspoint.co.uk  
Return-Path <paul-grass@stjohnspoint.co.uk>
Delivered-To grass-bugs@lists.intevation.de
Date Tue, 25 Mar 2003 14:45:09 +0000 (GMT)
From Paul Kelly <paul-grass@stjohnspoint.co.uk>
X-X-Sender paulk@agrippa.ukshells.co.uk
To grass-bugs@intevation.de
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #1759] (grass) d.what.sites slow and possibly wrong output
In-Reply-To <15999.23061.677960.709420@cerise.nosuchdomain.co.uk>
Message-ID <Pine.LNX.4.53.0303251440130.11162@agrippa.ukshells.co.uk>
References <20030324162508.8BFE713B4A@lists.intevation.de> <15999.23061.677960.709420@cerise.nosuchdomain.co.uk>
MIME-Version 1.0
Content-Type TEXT/PLAIN; charset=US-ASCII
X-Spam-Status No, hits=-1.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43
X-Spam-Level
I've fixed this by adding #include <math.h> to the start of the file
src/display/d.what.sites/what.c . Some other sqrt() function must have
been being used, which was giving the wrong answer. It also runs much
faster now.

Paul

> Request Tracker wrote:
>
> > Subject: d.what.sites slow and possibly wrong output
> >
> > Platform: Irix
> > grass obtained from: CVS
> > grass binary for platform: Compiled from Sources
> > GRASS Version: Latest CVS
> >
> > The latest CVS version of d.what.sites seems to give some strange output:
> >
>
> > It's also noticeably slower, e.g. half a second delay between the


Mon, Nov 17 2003 08:04:08    Comments added by hbowman  
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
Mon, Nov 17 2003 15:16:35    Mail sent by glynn.clements@virgin.net  
Return-Path <glynn.clements@virgin.net>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn.clements@virgin.net>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <16312.54737.829354.677347@cerise.nosuchdomain.co.uk>
Date Mon, 17 Nov 2003 14:06:09 +0000
To Harmisch Bowman via RT <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #1759] (grass) d.what.sites: very slow over a network connection
In-Reply-To <20031117070409.1DEEC13B53@lists.intevation.de>
References <20031117070409.1DEEC13B53@lists.intevation.de>
X-Mailer VM 7.07 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00
X-Spam-Level
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>


Comment | Reply | Take | Resolve

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request