[GRASS5] [bug #1759] (grass) d.what.sites slow and possibly wrong output
glynn.clements at virgin.net
Mon Mar 24 14:18:45 EST 2003
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
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
Glynn Clements <glynn.clements at virgin.net>
More information about the grass-dev