[Qgis-developer] comments on qgsvectorlayer.cpp
wonder.sk at gmail.com
Fri Aug 31 04:07:15 EDT 2007
On 8/31/07, Marco Hugentobler <marco.hugentobler at karto.baug.ethz.ch> wrote:
> On Friday 31 August 2007 02:36:25 Martin Dobias wrote:
> > 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.
> I also like the idea of a feature cache. Btw, it seems that the Java folks
> already do this, and there will be a presentation at the FOSS4G conference:
> Hopefully they will upload the slides later for those who cannot join (like
That talk looks very interesting...
> Additionally to a cache on feature level, it would also be good to have
> smarter zooming and panning as this enhances the user perceived performance.
> Similar to OpenLayers, a background thread could already render image pieces
> adjacent to the current view so that panning is a very fast operation. For
> zooming, I like the way of udig, where the image is scaled first and the
> rendered tiles appear successively.
I wanted to implement rendering in a background thread some time ago
to allow some features we really miss, like:
- interruption of rendering
- GUI interaction during rendering
- prerendering of areas near the border (as OpenLayers or GMaps do)
This needs a deep analysis of how it would work, where to put
synchronisation etc. and it will need also some architecture changes -
e.g. data providers do not provide thread-safe access, so concurrent
reads from providers would end up with incorrect results.
More information about the Qgis-developer