[Qgis-developer] Utilising QGraphicsScene in a first-class
fashion for QgsMapCanvas
morb at beagle.com.au
Fri Apr 13 06:58:27 EDT 2007
On Mon, 2007-04-09 at 20:15 +0200, Martin Dobias wrote:
> On 4/9/07, Brendan Morley <morb at beagle.com.au> wrote:
> > 2. Design
> > a. All drawable features are represented by a corresponding
> > QGraphicsItem.
> Important question is the performance when representing features as
> QGraphicsItems. Personally I'm in favour to use this implementation
> but definitely we should find out first if this won't eat too much
> processor time (and memory).
I can submit the code as a patch in email or as a new subversion branch;
then you can contrast and compare to your heart's content.
You can probably tell that my bias is to favour programming agility over
runtime capacity, especially if it's only a minor tradeoff.
You can also check out the Qt demo "chip".
> > 3. Deprecations
> > a. The QgsMapToPixel object is obsolete, since Map coordinates are
> > equivalent to Scene coordinates and Pixel coordinates are equivalent to
> > View coordinates.
> > b. The QgsMapCanvasMap is obsolete, since vector features can be added
> > directly to the QGraphicsScene rather than being abstracted through the
> > QgsMapCanvasMap.
> I'm not sure whether QgsMapToPixel should be obsoleted - when you're
> using only core libraries (no map canvas) there should be a simple way
> how to convert between the coordinates when doing something with
> rendered map.
What use-case would necessitate only the core library?
I remember a conversation maybe 6-12 months ago where we may have wanted
to render a map scene directly to an image file.
In the new paradigm, you would add your items to the QGraphicsScene and
then call QGraphicsScene.render() or QGraphicsView.render() (probably
more the latter).
> I can imagine when QgsMapCanvasMap can be a good option - in case you
> have many raster layers - each represented by one canvas item with a
> pixmap, the memory overhead can be big. When layers are rendered to
> one pixmap, you don't need a buffer for every layer.
Good point. Admittedly my bias is towards the vector eye candy (e.g.
tooltips) so this was a blind spot. I haven't actually progressed the
raster side too much yet.
> > 5. Benefits
> > a. I have already got incremental rendering working - this was broken
> > every since we ported to Qt4.
> What were the necessary changes?
Just keep adding QGraphicsItems to the QGraphicsScene, then do a
processEvents() at the desired multiple of added QGraphicsItems.
> > d. Ability to rotate the map with only a little extra code.
> > e. Qt4.3 looks like having perspective transformations. We can start
> > simulating those pseudo-3D road navigation devices!
> > (http://zrusin.blogspot.com/2006/09/perspective-transformations.html)
> Perspective transformations look very good. I'm currently developing a
> simple navigation and routing application (as a school project) based
> on QGIS libs + python and this looks like a must have feature :-)
Well we'll need to prepare the foundations then won't we? (-:
More information about the Qgis-developer