RE : [matplotlib-devel] Re: Speed of dynamic_image

John Hunter wrote:
> > My best guess: your numerix settings don't agree. This will 
> cause very 
> > poor performance, since the extension code has to fall back on the 
> > python sequence API (is this actually the correct 
> explanation of why 
> > it's slow, Todd?)

Todd Miller wrote: 
> I believe that's correct.  If matplotlib is compiled against 
> Numeric, the array API calls don't see arrays, they see 
> sequences (numarrays) which must be converted into (Numeric) 
> arrays.  This adds both constructor overhead and sequence 
> protocol overhead (almost certainly the dominant factor for 
> all array sizes).

Thanks a lot, I think it was that indeed! My fault for not reading the
FAQ!

Now I got around a 5 time increase in FPS, not the 10 FPS you have on
your computer but not too bad... :-)


I have redone my timings:

Classic TkAgg: 4.99 FPS

"Improved" TkAgg with no Agg realloc when h,w, DPI is constant: 5.18 FPS

FltkAgg (same as improved TkAgg, but use a new Agg tobuffer_rgba method
to reuse the Agg buffer instead of copying it: this is possible using
the fltk toolkit): 6.3 FPS

I still mainly measure the Agg drawing performance, so I did a new test
to check with a lighter drawing (included below, an annular mode (order
5) animation...)

Here are the timings for thoses:
Classic TkAgg: 9.98 FPS
Improved TkAgg: 10.6 FPS
FltkAgg: 16.7 FPS

These timings are with figures of the same size (it has an influence on
the FPS of course)

So it seems my optimisation has an impact, although moderate...
On the other hand, the copy mechanism induce some lag in the TkAgg
backend, while reusing the buffer in FltkAgg seems a nice
improvement...To check that, I disabled the copy in the TkAgg
(tkagg.blit call), and got 16.4 FPS).
I think thus my FltkAgg backend has the same speed as bare Agg, while
some optim are maybe possible on TkAgg (if Tk can reuse an extern
buffer, I am a complete beginner in Tk so maybe my conclusion are
invalid, if there is a flaw in my examples...

Depending on what you think of that, I can submit patches for the Agg
optimisation, exposing the Agg buffer as a python buffer object
(allowing buffer sharing instead of buffer copying, if toolkit support
this). For the fltk backend, I am ready to support it but it should wait
acceptance of some modif I made in the python bindings of fltk, for now
it does not work with stock pyfltk bindings... 

Best Regards,

Greg.