[SciPy-user] pyqwt or matplotlib
Tue Aug 26 15:54:50 CDT 2008
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 <email@example.com>
> > Subject: [SciPy-user] pyqwt or matplotlib
> > To: firstname.lastname@example.org
> > Message-ID: <48B3F6CF.email@example.com>
> > 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
> 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
> 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...)
More information about the SciPy-user