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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
