[Qgis-developer] Rendering with transparency -- slow

[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