[Qgis-developer] Rendering with transparency -- slow

[Marco Hugentobler]

+1

We really need to redesign some classes after 0.8 (and before 1.0). I agree 
fully with the mentioned points about vector and raster structures.

Talking about design questions, it would be nice to have a QPixmap free zone 
up to the level of maplayers and map rendering. This would be nice for custom 
applications which are using the qgis libraries and don't have access to the 
x-server (for instance server applications).

cheers,
Marco  

Am Donnerstag, 30. November 2006 13:27 schrieb Martin Dobias:
> On 11/30/06, Christoph Spoerri <cspoerri at cavtel.net> wrote:
> > Hi there,
> >
> > I diagrammed the data model currently used by the lib_refactoring branch.
> > While trying to understand the interaction of the classes and their
> > purpose, I saw that some classes share similar functions (e.g.
> > nextFeature in layer and provider classes), at the same time some classes
> > could be further refactored.
>
> Hi,
>
> you're right, this is a bit pain - they are nearly the same, just
> QgsVectorLayer adds support for added / changed / deleted features
> that haven't been propagated yet to provider. Really bad is that for
> getting features we usually use getNextFeature() from provider, not
> from layer - result is that with some operations you're unable to work
> with newly added geometries etc.
>
> > So, I went ahead and created a proposed data model, the way I would have
> > designed it. The idea behind the model is that we have two main classes:
> >
> > - QgsDataSet: used for data manipulation on a feature level (e.g. adding,
> > deleting, etc.), used in QgsMapLayer for rendering. This class would
> > contains methods such as nextFeature(), deleteFeature(),
> > updateGeometry(), createPyramid(), etc.
> >
> > - QgsDataProvider: used for data manipulation on a dataset level, e.g.
> > copy/deleting an entire dataset, format conversion, select subset of
> > features, etc.
> >
> > The QgsMapLayer classe(s) would only be used for rendering purposes, and
> > methods such as nextFeature, etc would be remove from the class.
>
> If I understand your design correctly, data provider should stay just
> as low-level data stores for different backends, data sets should
> provide most of the functionality that currently vector/raster layers
> implement and finally layers should work just as 'presentation' of the
> data set. This design look good to me from the first sight. Map layers
> can interface only with data sets, without having to use data
> providers directly. Data sets can organize data, probably adding
> functionalities that  provider doesn't implement (e.g. attribute
> indexing, spatial indexing, caching).
>
> Another big thing that's waiting for better design is QgsRasterLayer
> class. It's huge class with great amount of functions and very hard to
> catch up. Also it needs to change its architecture to enable raster
> data providers (similar to vector ones). Yes there is some kind of
> support already but it's quite weird and full of hacks.
>
> > Please let me know what you think. If folks think this approach makes
> > sense, I would be happy to continue developing the model and post my
> > progress for comments on the wiki site.
>
> I'd really happy to see some more investigation on this - possible
> problems, benefits, interfaces, diagrams, example use cases etc. :) go
> ahead!
>
> Regards,
> Martin
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.qgis.org
> http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer