On Tue, Oct 4, 2011 at 9:14 AM, Radim Blazek radim.bla...@gmail.com wrote:
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
Martin I just found that you proposed a patch to allow speed up vector
rendering
http://hub.qgis.org/issues/3200
maybe this can be tested again and added in time for 1.8?
Giovanni,
porting and testing the patch would need quite a lot of time.
Definitely not something that could
On Tue, Nov 1, 2011 at 9:38 AM, Marco Hugentobler
marco.hugentob...@sourcepole.ch wrote:
Martin I just found that you proposed a patch to allow speed up vector
rendering
http://hub.qgis.org/issues/3200
maybe this can be tested again and added in time for 1.8?
Giovanni,
porting and
Hi Martin
btw. the feature cache from #3200 is based on R-tree.
Wow, cool!
One question to the feature cache patch (didn't yet look into the code in
detail, so maybe a silly one):
Reading the usage notes of the QgsFeatureCache class, it seems to me the
implemented strategies are optimised
Hi Giovanni
Martin I just found that you proposed a patch to allow speed up vector
rendering
http://hub.qgis.org/issues/3200
maybe this can be tested again and added in time for 1.8?
Depends when the release should be.
Large modifications of the central core classes shouldn't be merged
Hi Marco,
Better is to consider it short after a release.
Ok, everything that speed up the rendering of (big) vectors is highly
welcome for testing.
Cheers
-- Giovanni --
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
On Tue, Oct 25, 2011 at 7:45 PM, Giovanni Manghi
giovanni.man...@gmail.com wrote:
Martin I just found that you proposed a patch to allow speed up vector
rendering
http://hub.qgis.org/issues/3200
maybe this can be tested again and added in time for 1.8?
Giovanni,
porting and testing the
i would also wait until after release of 1.8. It is probably too
dangerous before (without knowing it exactly).
Andreas
On Wed, 26 Oct 2011 10:49:56 +0100, Giovanni Manghi wrote:
Hi Marco,
Better is to consider it short after a release.
Ok, everything that speed up the rendering of
Hi,
On Wed, 2011-10-05 at 13:57 +0300, Alexander Bruy wrote:
Hi,
2011/10/4 Martin Dobias wonder...@gmail.com:
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.
Hi,
On Wed, 2011-10-05 at 13:57 +0300, Alexander Bruy wrote:
Hi,
2011/10/4 Martin Dobias wonder...@gmail.com:
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.
On Tue, Oct 4, 2011 at 9:37 AM, Marco Hugentobler
Did you measure with callgrind or any other tool. Maybe this explains the
difference (as Martin pointed out).
Callgrind, but for shp it should not make a big difference.
On Tue, Oct 4, 2011 at 6:07 PM, Martin Dobias wonder...@gmail.com wrote:
Hi Martin
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. 1+) for each feature type - points,
polylines, polygons. Any ideas for a free dataset?
Martin
Feel
Hi,
On Wed, 2011-10-05 at 13:57 +0300, Alexander Bruy wrote:
Hi,
2011/10/4 Martin Dobias wonder...@gmail.com:
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.
Hi Martin
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. 1+) for each feature type - points,
polylines, polygons. Any ideas for a free dataset?
2. write a benchmark
On Sun, Oct 2, 2011 at 9:33 PM, Marco Hugentobler
marco.hugentob...@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
On Mon, Oct 3, 2011 at 9:13 PM, Marco Hugentobler
marco.hugentob...@sourcepole.ch wrote:
Hm, I just see that UMN uses a normal select statement (not a binary cursor as
QGIS does). Don't know if that could make a difference, probably something for
me to test (the benchmark infrastructur should
Hi Radim
Did you measure with callgrind or any other tool. Maybe this explains the
difference (as Martin pointed out).
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
On Mon, Oct 3, 2011 at 3:22 AM, Marco Hugentobler
marco.hugentob...@sourcepole.ch wrote:
the time spent within postgres provider while waiting for server to
return the features may not be considered.
That might be a valid point. Is it better to use oprofile for the waiting
time?
OProfile is
On Tue, Oct 4, 2011 at 4:14 AM, Radim Blazek radim.bla...@gmail.com wrote:
On Sun, Oct 2, 2011 at 9:33 PM, Marco Hugentobler
marco.hugentob...@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
Hi Martin
how did you profile? Using callgind, oprofile or directly measuring
time?
It was with callgrind.
the time spent within postgres provider while waiting for server to
return the features may not be considered.
That might be a valid point. Is it better to use oprofile for the
In any case, the other servers in the benchmark had to fetch the features
from the same database
Hm, I just see that UMN uses a normal select statement (not a binary cursor as
QGIS does). Don't know if that could make a difference, probably something for
me to test (the benchmark
On Sun, 2011-10-02 at 15:02 +0200, cavall...@faunalia.it wrote:
I do not see reprojection of vectors significantly slowing down
rendering. Anyone does?
I do not. The real problem seems to me the rendering speed of
big/complex vectors, which can be very slow (overall and also compared
to other
...@gmail.com
A: qgis-developer qgis-developer@lists.osgeo.org
Oggetto: [Qgis-developer] Approximate reprojection for vectors
Data: dom, ott 2, 2011 14:40
Hi,
as you probably know, raster reprojection is using approximate
reprojection to get acceptable rendering speed. Now I am thinking
about
On Sun, Oct 2, 2011 at 4:33 PM, Marco Hugentobler
marco.hugentob...@sourcepole.ch wrote:
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
24 matches
Mail list logo
