On Tue, Oct 4, 2011 at 9:14 AM, Radim Blazek 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 it can be optimised,
On Tue, Nov 1, 2011 at 12:30 PM, Marco Hugentobler
wrote:
> 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 QgsFeature
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 fo
On Tue, Nov 1, 2011 at 9:38 AM, Marco Hugentobler
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 t
> > 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 someth
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 (big
On Tue, Oct 25, 2011 at 7:45 PM, Giovanni Manghi
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 patch would need quite
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
http://list
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 mer
Hi,
On Wed, 2011-10-05 at 13:57 +0300, Alexander Bruy wrote:
> Hi,
>
> 2011/10/4 Martin Dobias :
> > 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 e
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 wrote:
> Which version of
Hi,
On Wed, 2011-10-05 at 13:57 +0300, Alexander Bruy wrote:
> Hi,
>
> 2011/10/4 Martin Dobias :
> > 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 ea
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 benchma
Hi,
On Wed, 2011-10-05 at 13:57 +0300, Alexander Bruy wrote:
> Hi,
>
> 2011/10/4 Martin Dobias :
> > 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 ea
Hi,
2011/10/4 Martin Dobias :
> 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 data
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
On Tue, Oct 4, 2011 at 4:14 AM, Radim Blazek wrote:
> On Sun, Oct 2, 2011 at 9:33 PM, Marco Hugentobler
> > 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
On Mon, Oct 3, 2011 at 3:22 AM, Marco Hugentobler
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 a system-wide statistica
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 powe
On Mon, Oct 3, 2011 at 9:13 PM, Marco Hugentobler
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 still be in place).
Just an e
On Sun, Oct 2, 2011 at 9:33 PM, Marco Hugentobler
> 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 consum
> 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 infrastruct
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 wai
On Sun, Oct 2, 2011 at 4:33 PM, Marco Hugentobler
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 (QPainter->drawPolyline) was the most t
ply message -
> > Da: "Radim Blazek"
> > A: "qgis-developer"
> > Oggetto: [Qgis-developer] Approximate reprojection for vectors
> > Data: dom, ott 2, 2011 14:40
> >
> >
> > Hi,
> > as you probably know, raster reprojection
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?
... and my 5c.
I haven't looked at the code so the following may be inappropriate, but in
the late 80's my team (Sigmex Ltd) had the world's fa
I think Martin has profiled this problem and should have good data.
http://faunalia.it/pc
- Reply message -
Da: "Radim Blazek"
A: "cavall...@faunalia.it"
Cc: "qgis-developer"
Oggetto: [Qgis-developer] Approximate reprojection for vectors
Data: dom, ott 2,
Blazek"
> A: "qgis-developer"
> 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 think
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
I do not see reprojection of vectors significantly slowing down rendering.
Anyone does?
All the best.
http://faunalia.it/pc
- Reply message -
Da: "Radim Blazek"
A: "qgis-developer"
Oggetto: [Qgis-developer] Approximate reprojection for vectors
Data: dom, ott 2, 201
Hi,
as you probably know, raster reprojection is using approximate
reprojection to get acceptable rendering speed. Now I am thinking
about a possibility to implement the same also for vectors, to speed
up vectors rendering. What do you think about that? Does it make
sense?
Radim
__
31 matches
Mail list logo