[Qgis-developer] comments on qgsvectorlayer.cpp

[Martin Dobias]

On 8/31/07, Albert Cervera i Areny <albert at nan-tic.com> wrote:
> Thanks for your response Martin.
>
> A Divendres 31 Agost 2007, Martin Dobias va escriure:
> > 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...
>
> With Qt3 I've seen it documented but not with Qt4. I'd be nice to know if
> they've solved that, maybe not a problem for performance but quite ugly
> anyways...

Yup, it´s worth finding out if the problem with a crash with big zooms
doesn´t pop up anymore with recent versions of Qt (4.2 and later).


> > 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've been thinking about this and I've found that maybe the most intuitive
> thing I had done is to consider every polygon or groups of them (that is the
> result of drawPolygon for example) a new item in the QGraphicsView scene.
> Indeed, Qt4 has the QGraphicsPathItem class which holds a path and its brush
> (i think nothing else is needed). So qgis should only worry to create those
> items on demand and leave them created once they have been shown once. (Some
> enhancements could be done by removing some with some cache heuristics, but
> you get the idea). This way, no real cache is created, indeed QGraphicsScene
> holds the item for you and draws them when needed, and can make it's internal
> optimizations which is stuff that QGis won't have to worry about.

Well, there´s a small problem that we want to be able to use core
rendering routines also without the need to use QGraphicsScene (e.g. a
server that runs without X server). That´s why I think we should
develop our own caching mechanism which would work also when graphics
view is not used.

> In this case I don't quite see why zooming and moving should be a problem, as
> QGraphicsView has been designed exactly for this kind of things. Even for
> dragging and clicking the items if needed. You just create the paths
> (polygons, lines, ...) in QGraphicsPathItem's and Qt will handle translations
> and zooming etc. With the small view of all the architecture I have, it seems
> that QGis should only translate layer coordinates to scene coordinates.
> Rotation, zooming and translation should be handled in scene/view coordinates
> by Qt scene/view arquitecture.

Some time ago we had a patch here from Brendan Morley (I think it can
be still found on his blog on http://blog.qgis.org/ ) where he tried
to use directly graphics view items for vectors. The speed has been
reported by someone as pretty bad when using BIG layers, but probably
this could be improved somehow...

Martin