![](https://secure.gravatar.com/avatar/9ae4ce9eef0ed502005163f51792af3a.jpg?s=120&d=mm&r=g)
On Tue, 2008-08-26 at 22:12 +0200, Pierre Raybaut wrote:
Message: 4 Date: Tue, 26 Aug 2008 14:27:59 +0200 From: bernardo martins rocha <bernardo.rocha@meduni-graz.at> Subject: [SciPy-user] pyqwt or matplotlib To: scipy-user@scipy.org Message-ID: <48B3F6CF.2010600@meduni-graz.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi everybody,
I'm starting to write a program with PyQt to visualize some traces from a system of ODEs. I would like to plot one graphic for each variable inside this PyQt application...and I'm wondering which one is the best for it: matplotlib or pyqwt? I will read some files using PyTables and then I'll plot everything and some of these files are very big, so I need something fast and good.
I've been using matplotlib for some small programs and it's very nice, powerful and beautiful. I've already embedded some matplotlib plots inside a PyQt application. But I have the impression that pyqwt is faster than matplotlib. Is it true? Is there another library for plotting that would do the job?
Thanks! Bernardo M. Rocha
Hi,
That is not an impression: PyQwt is much faster than matplotlib and is often used precisely to analyse huge data sets (here is an example: http://pyqwt.sourceforge.net/images/meq.pdf -- simple plotting, but very effective). On the other hand, as you may know, matplotlib has *a lot* more features, but if you don't need them...
Which is faster depends critically on whether you need antialiased drawing or not and also the content of the plots. I've been banchmarking the rendering speeds for large polylines, for an in-house plotting widget, using a variety of libraries. Matplotlib (mostly) uses the Antigrain (AGG) antialiased rendering library. For AA-plots with moderate-to-large numbers of vertices (say
1000), this seems to be the fastest rendering method. Bascially, none of the main native drawing APIs (cairo, Qt, GDI+, Quartz) yet use hardware-acceleration for diagonal line rendering (they all focus on efficient compositing and text rendering), so an optimised software-rendering library like AGG wins (by about a factor of 3 on the few machines I tested it on).
One exception here is if Qwt can use the QGLWidget (in Qt4), which renders using OpenGL (I'm not 100% sure if it can, since I've not used Qwt much). If your hardware supports antialiasing with OpenGL, then this can lift the performance well above AGG. The rendering speed and quality is rather variable however, depending on hardware. Other factors could also interfere with OpenGL performance: if you need many plot windows, having an OpenGL context for each plot could also kill performance. Another exception may also be for scatter plots with a symbol at each point. The newer drawing APIs place a lot of emphasis on glyph rendering performance (for text rendering). If the points are rendered using the glyph-caching facilities of cairo, for example, this may beat AGG. I haven't tested this yet, however. I havn't checked how mpl does symbol rendering, so I'm not sure if this changes the mpl-vs-qwt question. On the other hand, if you don't need antialiasing, rendering can go *much* faster (by a factor of 10 or more) using the native APIs. Using OpenGL can increase non-AA rendering speed even further. However, Idon't think you see this speed improvement in matplotlib, with the non-Agg backends. For example, drawing polylines in wxPython from arrays of data is limited by the slow speed of sequence-iteration over arrays. When I pre-convert all my data-arrays to lists, the wxDC:drawLines calls go 5x faster. A C-function to pass the array data directly to the wxDC increases speed further still. Summary: If you want antialiased plots, matplotlib should be fastest (except if Qwt can use antialiased OpenGL). For aliased plots, Qwt will be fastest, since rendering will no longer be the bottleneck and the 100% C++ implementation of Qwt will pay off. An OpenGL backend to matplotlib would be sweet... This is an interesting topic for me (as you can probably tell...) BC
Pierre