[GRASS5] Re: Grass GUI - mouse 100% CPU bug and alternatives to i.points

[Hamish]

> > > You asked for it. So here comes. (; Georeferencing UI is EXTREMELY
> > > bad. When I run I.points I also have to open qgis with another map
> > > of the same location to get the real co-ordinates
> <snip>
> 
> > If I understand it well, this is already the way, i.points works(?)

That's i.vpoints I think.

> > -- one can open 4 frames in GRASS-monitor -- the left half is used
> > for currlently source location, the right half is used for
> > displaying maps from target location. it is not necessary to set the
> > coordinates by hand, you can "click" them in the target map.

I seem to remember in GRASS 5pre days that i.points would let you use at
least 3 of the four frames for different levels of zooming. These days
only the left two seem to get used?


> I wish i.points functionality could be implemented into QGIS
> georeferencer plugin... As well as other warping methods, as presently
> QGIS provides only Helmert's AFAIR.
..
> BTW - that'd be great if Grass could use Gdal warping - the speed and
> reliability.

FWIW, GRASS and GDAL's 1st,2nd,3rd order warping are all started out as
the same base code. e.g. they both have the same 3rd order bounds bug.
Difference is that Frank's version was and is better maintained.
Additionally gdalwarp now has a really nice thin-plate-spline warping
method which would be great to use in GRASS. GDAL is a manditory
requirement for GRASS 6, so I am all in favour of ripping out GRASS's
version and using calls to the GDAL warp API instead.

see:
 https://intevation.de/rt/webrt?serial_num=3166
 https://intevation.de/rt/webrt?serial_num=2952


> > > Oh and BTW the CPU spikes
> > > up to 100% and my laptop fan starts to go on overdrive everytime I
> > > run i.points... Is there a busy loop somewhere in the code?
> 
> You haven't heard my laptop yet ;). But what's really bad is that this
> bug hampers Grass usability in a network where one machine is a server
> for several Grass sessions - imagine all the users trying to use
> i.points / other mouse intensive operation in the same time. Has
> anybody got an idea how to get rid of this bug?

search the mailing list archives. Trouble (as I understand it) is the
quick-fix-the-symptom solution is to add a usleep() call for a couple of
milliseconds between each check for a mouse event. But the only portable
sleep() function seems to be the one which only lets you sleep for full
seconds, which ruins the responsiveness. A hack solution would be to
check for usleep() or similar and then use if it we have it, otherwise
encounter the 100% cpu usage. That's pretty crappy though.

better to either a) revert the change (no problem in GRASS 5) and/or b)
write something better.

the problem: someone needs to do it.



Hamish