[Qgis-developer] comments on qgsvectorlayer.cpp

[Martin Dobias]

On 8/31/07, Albert Cervera i Areny <albert at nan-tic.com> wrote:
> Recently I've been taking a look a the vector layer source code and trying to
> find with the help of valgrind and kcachegrind where most of the time was
> spent. With the files I took I started playing a bit and it seemed that most
> time was spent in the drawPolygon function. Not a big surprise given the
> sample data, but a good place to start.

Hi Albert,

more than a year ago, I've made also some tests to see where we could
gain some more speed when working with vector layers:
http://wiki.qgis.org/qgiswiki/Rendering_Performance

These tests were done back in times of Qt4.1.x, so drawing times might
be different now. Also Trolltech was announcing that in Qt4.3 they've
increased performance of drawing to OpenGL, but I haven't tried it
yet.

The tests were done by simply measuring overall time with QTimer calls
inserted into the code. From the tests I would say that the biggest
bottlenecks is data retreival from data providers. We don't have any
caching mechanism so the data are usually always re-read from the data
store (well, there are disk caches but they're at much lower level).

>         I looked at it and tried to redo some things to find if I could do something
> to improve performance. The result, no performance gain, at least no user
> perceivable difference, but the code seemed much clearer because path is
> filled in the first loop. However, to achieve that I removed the code
> responsible for clipping values that don't fit into 16-bit signed values as
> it seems that was a Qt 3 limitation and Qt4 possibly has an internal
> solution/workaround for that. (At least I see no warnings in Qt4 docs). If
> that code is correct, then something similar could be done for drawLineString
> and drawFeature.

That clipping code has been added to overcome a nasty bug with Qt3 on
X11 platform where we were getting freezes of the whole system. But
also for Qt4 we had to leave it there - in Qt4.1.x QGIS was crashing
sometimes at greater zooms during the rendering. Maybe it's not a
problem anymore with Qt4.2 or 4.3 as Trolltech devs tried to make the
drawing routines more roboust, but I don't know if this was fixed too.
Anyway, the clipping amgorithm is pretty fast and IIRC removing it was
just about 1-2% performance gain - not a big deal...

>         Please, see attached a diff for current trunk. Of course that's working fine
> in my tests.

I've seen the patch, but as I've said I'm not much a fan of removing
the clipper as it doesn't make a big difference and there's
potentially still the problem with a crash. There are surely other
places that need some optimizations more. The elimination of those
intermediate arrays for rings is good though...


>         By the way, as I said what I wanted to find is a way to improve performance.
> For example with the map of spain I've been playing it takes 4 seconds to
> repaint the hole map with 3 layers (1 with polygons and a couple with lines).
> Looking at the code a possible solution that comes to mind would be to try to
> keep the generated polygon (or line or whatever) path from one call to
> another, maybe adding polygons in the path on demand when the user moves. I
> imagine that would mean redesigning the the way zooming and scrolling is
> handled. But probably I'm also ignoring many other aspects, as I've only
> worked with a very little part of the source code.

I've been thinking about this - mostly about where to put the caching
mechanism. There are generally two options:
- cache objects ready for painting (as you suggest) - e.g. save
ready-made QPolygonF instances
- cache objects fetched from data provider - e.g. save QgsFeature instances

I like the second option more due the fact you're mentioning - when
scaling or scrolling we would need to recalculate the coordinates
somehow. More clean way seems to me to cache the features with their
map (not screen) coordinates.

>         Any way, I was interested in knowing how it all worked and try to find out if
> there've been some discussions regarding theses performance issues.

It's great to see that some people look into the QGIS code and try to
improve it! I'm looking forward to see here some more discussion about
the rendering performance.

Regards
Martin

P.S. nowadays I'm moving to my new place so I'll be probably less
responsive until I settle down.