[Qgis-developer] Approximate reprojection for vectors

[Martin Dobias]

On Tue, Oct 4, 2011 at 4:14 AM, Radim Blazek <radim.blazek at gmail.com> wrote:
> On Sun, Oct 2, 2011 at 9:33 PM, Marco Hugentobler
> <marco.hugentobler at sourcepole.ch> > I did a lot of profiling for the
> FOSS4G WMS benchmark (osm data, reprojected to
>> google crs, complex symbology with a lot of rules). The pattern was mostly the
>> following:
>> the rendering itself (QPainter->drawPolyline) was the most time consuming
>> operation (appr. 50% of rendering time),
>
> I always thought that Qt4 rendering engine is quite efficient. Also in
> my case (I am testing with Shapefile) QPainte::drawPolyline takes only
> 0.05% (!!!), it seems that I am looking on some wrong results comaring
> to your 50%, but I cannot find what am I doing wrong.
> Could it be that a different paint device is doing the difference? But
> when rendering on screen, we are using QImage or QImage anyway and in
> that case graphics card's power is not used, is it?

Qt4 rendering should be quite fine performance-wise. But there are
some paint operations that are slow anyway - antialiasing, thick lines
(must be convert to polygon!), drawing with opacity etc. This is a
good reading material:
http://labs.qt.nokia.com/2009/12/16/qt-graphics-and-performance-an-overview/
http://labs.qt.nokia.com/2009/12/14/qt-graphics-and-performance-whats-hot-and-whats-not/

In any case we should look into the performance in a more coordinated way:
1. choose a dataset for testing - ideally just 1-3 layers of real data
with lots of features (e.g. 10000+) for each feature type - points,
polylines, polygons. Any ideas for a free dataset?
2. write a benchmark that could be run repeatedly easily - I would
volunteer to provide it
3. test and analyze the results
4. optimize bottlenecks


>> next was evaluation in rule based
>> renderer (20% of time), getNextFeature in PostgresProvider 10%, coordinate
>> transformation 10%.
>
> In my case, with Shapefile, QgsOgrProvider::getNextFeature is taking
> over 50% and most of it is strcasecmp in GDAL (probably because of
> unnecessary calls from QGIS (for Frank, if you are reading this)). I
> believe that it can be optimised, I'll look at it.

Which version of GDAL? From 1.8 there are some important enhancements,
mainly in case that the shapefile consists of lots of features.

Martin