after spending a nice afternoon profiling the dynamic
examples and looking a bit through the code, we can make
a few comments on the performace of the wx backends.
We have used kcachegrind to display the results of
hotshot - all files can be found under
WxAgg leaves the composition of the plot frame to the agg backend
and blits the calculated picture to the screen. The agg backend seems
to be quite efficient since we could not find any predominant
But, agg and wx use different image formats, therefore the picture
has to be transformed using wx.Image.ConvertToBitmap which is
a deprecated wx method.
On the other hand, gtk-agg uses the C++ routine
agg_to_gtk_drawable which seems to be faster.
Optimising the agg to wxPython conversion
could lead to a similar speedup.
Because wxAgg leaves the drawing to agg it is faster than the
As Chris Barker correctly presumed the wx backend doesn't do any
caching. Therefore about 15% of program time is spent in the
freetype2 library (ft2font.FT2Font) and another 7% for changing
wxPens wxBrushes and sizes. So storing all this information on the
python level (and only altering it if there is a change) would
lead to a first performance increase.
(draw_text and set_foreground branch in the picture)
The wx device context (wxDC) is not passed as local variable or
instanced as global but selected for every drawing operation and
The drawXXXs (note the plural) commands in wx expect the
input to be an array of points. The following line of code
is from the wx-backend.
gc.DrawLines([wxPoint(int(x[i]), self.height - int(y[i])) for i in
Avoiding the explicit loop and
vectorizing the expression should give another speed increase
Nikolai and Arnd
+++ Sparen Sie mit GMX DSL +++ http://www.gmx.net/de/go/dsl
AKTION f�r Wechsler: DSL-Tarife ab 3,99 EUR/Monat + Startguthaben