[Qgis-developer] Render speed
marco.hugentobler at karto.baug.ethz.ch
Thu Jan 10 03:06:26 EST 2008
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...
Am Donnerstag 10 Januar 2008 01:01:38 schrieb Tim Sutton:
> 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
> 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
Technical Advisor QGIS Project Steering Committee
More information about the Qgis-developer