Render speed

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Render speed

Magnus Homann
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
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Render speed

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 <[hidden email]>:

> 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
> [hidden email]
> http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
>


--
Tim Sutton
QGIS Project Steering Committee Member - Release  Manager
Visit http://qgis.org for a great open source GIS
openModeller Desktop Developer
Visit http://openModeller.sf.net for a great open source ecological
niche modelling tool
Home Page: http://tim.linfiniti.com
Skype: timlinux
Irc: timlinux on #qgis at freenode.net
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Render speed

Hugentobler  Marco
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 <[hidden email]>:
> > 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
> > [hidden email]
> > http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer



--
Dr. Marco Hugentobler
Institute of Cartography
ETH Zurich
Technical Advisor QGIS Project Steering Committee
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Render speed

Magnus Homann
Marco Hugentobler wrote:

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

Good idea, I was thinking about using the test framework that we have
for running performance test. With the same computer system, the numbers
should be relevant before/after.

I propose Tim look into this after we got 0.9.2 out, start by
implementing tests that show the weakness *before* we do any changes.

Magnus

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Render speed

Albert Cervera Areny-2
In reply to this post by Hugentobler Marco
>
> - 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

Indeed, caching should be done for all backends, GML is very slow, and others
could see a performance boost too, acording to previous discussions. Not
volunteering right now, though ;)

> - parallel rendering of layers on multicore processors
> - on-the-fly generalisation of complex geometries (only upon user request!)
>
 
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Render speed

Tim Sutton
Hi

Other things we could to the list (though they may be out there in
dreamland...):

 - prevent unneccessary rerendering of a scene by using composition
management (no idea if this is viable with QGraphicsScene though)
 - prerendering off screen areas in a background thread
 - composit each layer to screen as it is rendered
 - go trough all rendering loops and move as much if..then...foo logic
to outside of the loop - for exmple pre-create all brushes and pens
before the loop and then just select the appropriate one from the
brushes and pens collection during render loops.
 - get people like Frank Warmerdam to review main render loops to see
if are accessing data in most efficient way possible

and my final tougue in cheek option:

 - dont permit canvas size greater then 100x100px and issue each user
with a large magnifying glass

About three years ago a colleague and I would regularly test render
performance of QGIS by comparing rendering the same datasets (vector
and raster) against ArcView and ArcMap on the same (dual boot
machine). QGIS did pretty well then with the exception of being slower
at rendering large vector scenes when zoomed out. This is a useful
metric to use since these apps are the standards against which many
users will measure how fast QGIIS is. I no longer have access to Arc*
apps but Im sure there are obliging users out there who can help.

I will be more than happy to write some benchmarking unit tests too..

Regards

Tim




2008/1/10, Albert Cervera Areny <[hidden email]>:

> >
> > - 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
>
> Indeed, caching should be done for all backends, GML is very slow, and others
> could see a performance boost too, acording to previous discussions. Not
> volunteering right now, though ;)
>
> > - parallel rendering of layers on multicore processors
> > - on-the-fly generalisation of complex geometries (only upon user request!)
> >
>
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
>


--
Tim Sutton
QGIS Project Steering Committee Member - Release  Manager
Visit http://qgis.org for a great open source GIS
openModeller Desktop Developer
Visit http://openModeller.sf.net for a great open source ecological
niche modelling tool
Home Page: http://tim.linfiniti.com
Skype: timlinux
Irc: timlinux on #qgis at freenode.net
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Render speed

Albert Cervera Areny-2
A Dijous 10 Gener 2008 11:29, Tim Sutton va escriure:
>
>  - prevent unneccessary rerendering of a scene by using composition
> management (no idea if this is viable with QGraphicsScene though)

I suggested this earlier by Martin said it wouldn't be possible if we want to
keep the renderer without any dependencies on QtGui, so it can be used
without an X server. Or maybe another layer could be added...
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Render speed

Martin Dobias
On Jan 10, 2008 6:29 PM, Albert Cervera Areny <[hidden email]> wrote:
> A Dijous 10 Gener 2008 11:29, Tim Sutton va escriure:
> >
> >  - prevent unneccessary rerendering of a scene by using composition
> > management (no idea if this is viable with QGraphicsScene though)
>
> I suggested this earlier by Martin said it wouldn't be possible if we want to
> keep the renderer without any dependencies on QtGui, so it can be used
> without an X server. Or maybe another layer could be added...

Just to clarify: QGIS core library depends on QtGui (since that module
contains all the stuff like QPainter, QImage etc.) but it is designed
that it can run without a running X server.

Composition manager can be implemented in QGIS gui library and could
use QGraphicsView facilities. We can do it by drawing each layer to
another graphics view item (instead of drawing them all to one item).

Martin
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer