[Qgis-developer] Render speed

[Marco Hugentobler]

Hi,

I couldn't agree more. Performance is a very critical aspect for any GIS and I 
like the idea of a performance triage for 0.9.3 very much.

Usually difficult is how to measure performance. Maybe we could publish some 
free benchmark datasets on the qgis website and put a timer into qgis code 
that outputs the rendering time on console. Then someone that does a 
performance improvement may communicate the rendering times for the benchmark 
datasets with/without improvement.

One point that is also important in the context of performance is to have a 
responsive application. A long program action is more likely to be tolerated 
by a user if there is feedback about the progress and if users have the 
possibility to cancel that operation.

So I can imagine quite some actions to improve performance/responsiveness 
(some of them located in feature dream land of course :-) )

- possibility to cancel long rendering operations (as described by Martin)
- a faster attribute table based on model/view (as described by Tim)
- caching of WMS tiles for fast panning actions by WMS provider
- parallel rendering of layers on multicore processors
- on-the-fly generalisation of complex geometries (only upon user request!)

I'm sure there are a lot more...

Regards,
Marco





Am Donnerstag 10 Januar 2008 01:01:38 schrieb Tim Sutton:
> Hi
>
> I cant remember who I was chatting to on IRC but I was going to
> suggest that 0.9.3 we focus our attention on perfrmance only (kind of
> like a performance triage!). Its definately an often mentioned
> complaint and we should really be striving to get QGIS faster with
> each release...particulary once we have all features implemented for
> 1.0.
>
> Regards
>
> Tim
>
> 2008/1/9, Magnus Homann <magnus at homann.se>:
> > I did a VERY unscientific test, rendering a 200 x 200 and a 300 x 300
> > points shape file in trunk, renderer branch and composer_redesign
> > branch. The points were autogenerated from a C-program to a delimited
> > text file and then saved as shape file. All branches were compiled with
> > debugging off.
> >
> > Using circles with size around 20, in renderer branch larger.
> >
> > Result:
> >
> > branch          layer    sec
> > ----------------------------
> > trunk           200x200      4
> > trunk           300x300      8
> > render          200x200      7
> > render          300x300      13
> > composer        200x200      16
> > composer        300x300      32
> >
> > The delimited text files (gzipped) for those interested are stored at
> > links below. It would be good if anyone could confirm the discrepancies.
> >
> > http://homann.se/Qgis/del200x200.txt.gz
> > http://homann.se/Qgis/del300x300.txt.gz
> >
> > Magnus
> >
> >
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.qgis.org
> > http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer



-- 
Dr. Marco Hugentobler
Institute of Cartography
ETH Zurich
Technical Advisor QGIS Project Steering Committee