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

[Glynn Clements]

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 at virgin.net>