[Merkaartor] Qt Graphics View - why not used?

hermann+merkaartor at tfp.uni-karlsruhe.de hermann+merkaartor at tfp.uni-karlsruhe.de
Fri Nov 21 14:49:12 GMT 2008

Hi Chris,

On Fri, Nov 21, 2008 at 12:57:25AM +0100, Chris Browet wrote:
> 2) I tried once to make the switch but abandoned because it was a
> hell of a job and...

That's true. However, it boils down to inheriting MapView from
QGraphicsView and MapFeature from QGraphicsItem. Of course, a lot of
details have to be taken care of.

> 3) I'm not at all convinced performance would be better. Principle
> of Graphic view (as I understand it) is that you draw everything and
> Qt handles the rest. Although panning would probably be faster,
> having to "draw" everything first would mean high latency before
> first display, ...

Well, drawing the features should be as fast as it is in the current
implementation of merkaartor. Trolltech claims to be able to support
thousands of items on a QGraphicsScene. They have an efficient
mechanism to update only the part of the view that is affected by the
item's bounding box, they use caching, etc. I'm not sure whether the
current code in Merkaartor can compete with this framework. But I'm
still in the stage to get an overview, so maybe I missed some key
things there.

> ... this every time the zoom level changes (have to redraw because
> not every feature is displayed at all zoom levels) ...

One can switch on/off QGraphicsItems easily without redrawing the
whole scene.

> ... and far greater memory consumption, which would probably make
> low spec machines swap a lot with large areas downloaded.

Maybe. I don't know how good/bad the memory footprint of the
QGraphicsScene framework compares. They build their library for
handhelds as well, so I guess it's not that bad.

> 4) Graphic view being a "middle-level" api, I assume it ought to be
> slower (due to the overhead) that the "lower-level" api we are
> using. If it is not, it only means that we are not efficiently
> painting as we are now.

Yes, in the end, I fear, you are optimizing the current code and
reinvent all the stuff which the Qt ("cute") guys have already put
into QGraphicsScene under the hood. That's not meant as criticism, I
just want to express that IMHO a "middle-level" API is often superior
to a "low-level" interface, including the efficiency aspect.

> 5) drawDownloadedArea is a good example of something hard to
> implement the Graphic view way. Basically, it would mean drawing red
> dots on the Graphics view equivalent of the whole world, besides tiny
> rectangles where data has been downloaded. I'm not sure this would be
> efficiently handled by Qt.

I don't know.

> Bottom line is that it would have been easier and cleaner to use at
> the very beginning, but nowadays would be mucho work to switch with
> no sure benefits...

Well, it may at least be an interesting project to get acquainted with
merkaartor and the QGraphicsScene framework. :-) I'll digg a little
bit deeper into that and will see what comes out.



More information about the Merkaartor mailing list