[Qgis-developer] Summer of code project

[Jae Sammy]

Martin,

That's hard to say since one man's fast is another man's slow.  From an application point of view I think the right answer is, can it be faster?  For my situation where only one point is changing I would expect the fastest to be how fast can a single point be read from a database, the point drawn on the map, and the pixels vacated by the point be drawn on the map.  This should be blazing fast.  As it stands now this takes (depending on what else is loaded) upwards of a second to do.  Considering the gui is not accepting input during this second, it feels more like an eternity for the user.

I don't see why all the layers need to be refreshed on a pan/zoom.  Only the layers involved in the new map extents need to be refreshed.

Unfortunately, I don't have any experience with the new render caching and can't really upgrade at this point but it sounds cool.  I just wonder if that is re-inventing the wheel.

>From Qts docs, "it can visualize large scenes in real-time, even with millions of items".  It seems a shame to not use this since it seems to be designed almost specifically for gis.

Jae C. Sammy

-----Original Message-----
From: Martin Dobias [mailto:wonder.sk at gmail.com]
Sent: Monday, April 05, 2010 2:17 PM
To: Jae Sammy
Cc: qgis-developer at lists.osgeo.org
Subject: Re: [Qgis-developer] Summer of code project

Hi Jae

On Mon, Apr 5, 2010 at 9:20 PM, Jae Sammy <jcs at rincon.com> wrote:
> Martin,
>
> This project sounds like a great idea!
>
> I came across the following potential optimization while trying to optimize my map refreshing in a project where I had a large number of static rasters under a small number of vector layers that were changing frequently under a large number of vector layers that were changing infrequently.  Ideally this called for the ability to refresh each layer individually and the map to only redraw the pixels that were affected by the change.

How long does the rendering take now and what would be an acceptable
time for you? Anyway note that when map canvas is panned or zoomed,
_all_ map layers have to be rendered again even if there were some
optimizations.


> Currently, qgis doesn't take full advantage of Qt's native graphics view framework since all layers are rendered down to a single qgraphicsrectitem (qgsmapcanvasmap) and placed in a scene by itself.  A possible optimization is to play nicer w/ Qt and have all layers implement their own qgraphicsitem and add them to the qgraphicsscene (currently instantiated in qgsmapcanvas) in order based on their order in the layerset.  This way qt will only render what is needed and each item can inform the scene of the changes to its bounding rectangle so that only a subset of the scene is re-rendered.

This optimization is surely possible. Render caching introduced
recently actually does a very similar thing. Personally, I think that
rendering all layers into one graphics item is a better option than
having one item per layer: the blending of layers is done just once
per redraw, I believe that when using "item per layer" approach, the
rendered images of layers will have to be blended together on every
update - that means also when drawing rubber bands on top of the map
(e.g. for measuring), when panning etc. And that could be much slower.
But I may be wrong...

Regards
Martin