[Qgis-developer] Summer of code project

[Martin Dobias]

Hi Jae

On Tue, Apr 6, 2010 at 1:55 AM, Jae Sammy <jcs at rincon.com> wrote:
> 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.

If I get accepted to SoC, this is one of the important things I'd like
to address: allow users to do arbitrary map browsing even if the
application is rendering map.


> 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.

Well, every time you zoom or pan, the map extents changes so there is
always a region that wasn't rendered previously (apart from zooming
in, but there could be scale-dependent rendering set up). So data
sources for all layers must be asked what features are in the new
extent so that the application can draw them.


> 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.

I believe the reason for that statement is that they are using spatial
indexing (bsp tree) and caching. If we were going to represent each
feature by a graphics item, there would be new problems: all features
would have to be loaded into memory, if the symbology is modified, the
items might have to be repositioned (and reindexed) etc. Simply put,
the overall performance could suffer. Note that these are just my
hypotheses, I haven't actually tried it out.


Martin