Buone notizie: Radim ha affrontato il problema della velocita' di
rendering in QGIS.
Ci aspettiamo risultati interessanti. Saluti. -------- Messaggio originale --------
Hi, because I found QGIS to be terribly slow with larger vectors, I started to work a bit on rendering optimization. I am still at the beginning of the work, here are some first findings. The first step was to get some reliable benchmarks, for which I wrote a new CLI application, mostly derived from qgis main app (tests/bench, installed as bin/qgis_bench). I found precise and repeatable CPU time measurement quite problematic, my observations are summarized in tests/bench/README [1]. Any idea how to measure time better is welcome. Preparing projects for qgis_bench application, I noticed that qgis renders the same project much slower than qgis_bench. I found that QgsMapCanvasMap was using by default QPixmap, not QImage, which is 7 times slower! To be precise, QGIS was using QPixmap by default, but in options GUI was set as default QImage. If "Fix problems with incorrectly filled polygons" is unchecked (default), QImage is used. It means that it was sufficient to open options dialog, apply (not changing anything) and QgsMapCanvasMap started to use QImage. Obviously, this could not be noticed by developers and advanced users, because they had used options dialog at least once. Naive users (like me), who rely on default settings, were using QPixmap. It seems, that since 2006, all the first-time users (and thus maybe also last-time users) were experiencing this problem. Is it possible or am I wrong? Hopefully. Having fixed this problem (fixed in master [2]), the true optimization may start. Here are some preliminary benchmark results for master: http://www.mpasol.it/blazek/qbench/ Y axis is relative rendering time (oldest build time = 100%). X axis is commiter date for each build. Changes about 1% are not significant (benchmark inaccuracy). You can place mouse over each point to get tooltip with more info. It is also possible to zoom in both main chart and overview. You may notice, that something bad has probably happened between 8c1c2add and 1d7d1c62 (if there is no bug in my scripts). You can also see that effect off each change in code depends a lot on data type. It is important to say, that most of the optimization was already done by Martin Dobias during GSoC 2010, see his report [3]. Unfortunately most of them were not yet merged to master. 8c1c2add (see the chart), is one of those (the only one?) which have been merged, the speed up is significant. My next plans are: 1) add more projects (more data types and rendering modes) to my benchmark suite 2) add older builds (as old as possible - where qgis_bench runs with old libs without recompilation) 3) localize (in time) bigger performance jumps 4) merge optimizations from dev-threading branch (maybe Martin is going to do that?) Any comments are welcome. Radim [1] https://github.com/qgis/Quantum-GIS/blob/master/tests/bench/README [2] https://github.com/qgis/Quantum-GIS/commit/6e1d38c13969dab132f877c55c6ccbf9c7f3167b [3] http://www.qgis.org/wiki/QGIS_on_steroids_GSoC_2010 _______________________________________________ Qgis-developer mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 540 iscritti al 4.11.2011 |
Free forum by Nabble | Edit this page |