[GRASS5] [bug #1759] (grass) d.what.sites slow and possibly wrong output

GRASS GRASS developer
1

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

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

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

2

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>

3

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