[GRASS-dev] Re: [Qgis-developer] Re: Value tool plugin makes QGIS crash

[Hamish]

Radim wrote:
>>> If there are 10 maps open in QGIS, it starts 10000 executables
>>> in about 1 second. That is probably a bit slow.
Hamish:
> > It can also take multiple input coords in a single call, so
> > you can at least queue you queries into bigger sized chunks
> > if you like, which would ease the pain a little.
> 
> Maybe, but probably source of other problems, because it has to
> be implemented in GRASS provider, and that means to add a
> little delay to find if there are more values requested and
> that is not desired for all tasks.

To be honest I doubt there's much point in queuing a burst of
queries, but a 100-500ms delay between individual queries would
both greatly cut down on the number of process calls and not be
very noticeable to the user. Doesn't totally solve the problem,
but it would help to mitigate it.
what tasks is that not desired for? It can't be restricted to the
mouse-over bits?

> > as a long term solution, would a from-scratch LGPL native GDAL
> > driver help? ... Possible Summer of Code project for someone?
> 
> Do you mean de facto new GRASS raster library? Thread safe,
> exceptions support etc... That could help.

Not really, I mean re-writing the GDAL grass6 raster plugin from
scratch to not depend on the existing GRASS GPL libraries.
We want this in place anyway so we change change the raster
format/file structure in GRASS 7 but still allow users to access
old GRASS 6 maps seamlessly using the r.external module (which is
a live frontend to GDAL). Also, it has been a long-time wish to
donate such a thing to GDAL but under LGPL license so that GDAL
could in future have less trouble with competing plugin licenses
(see  http://trac.osgeo.org/gdal/wiki/rfc34_license_policy).
If it happened to be tread safe, etc, well, all the better.


Hamish