Speed of dynamic_image

Development matplotlib-devel
1

  It seems thus that Agg drawing is the main limiting

    > factor here, all the tricks to avoid using strings (or
    > reallocating Agg renderer, for that matter) are not too
    > usefull... What I do not understand is why I got such
    > low values, compared to the 4 or 10 FPS: I guess, given
    > the impact of Agg drawing, all the *Agg backends should
    > have about the same speed...Is there something I miss
    > here? My workstation is not current top of class, but
    > it's a PIV 2.3 GHz, so certainly not slow either...I do
    > not think the graphic subsystem is at fault, cause except
    > for a mistake of my part, blit only test shows that Agg
    > is really the origin of the poor FPS...

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?)

  http://matplotlib.sourceforge.net/faq.html#SLOW

To make sure, rm -rf the matplotlib build dir and the
site-packages/matplotlib install dir and rebuild with NUMERIX =
'numarray' in setup.py, and make sure numerix is set to numarray in
your rc file.

I get 10FPS on the example you posted (3.4GHz P4). It's a faster
machine than yours, but it's not 10 times faster. If I use numarray
in my rc file and build with Numeric, I get 1.6FPS.

JDH

2

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

Regards,
Todd

···

On Thu, 2004-07-15 at 10:25, John Hunter wrote:

    > It seems thus that Agg drawing is the main limiting
    > factor here, all the tricks to avoid using strings (or
    > reallocating Agg renderer, for that matter) are not too
    > usefull... What I do not understand is why I got such
    > low values, compared to the 4 or 10 FPS: I guess, given
    > the impact of Agg drawing, all the *Agg backends should
    > have about the same speed...Is there something I miss
    > here? My workstation is not current top of class, but
    > it's a PIV 2.3 GHz, so certainly not slow either...I do
    > not think the graphic subsystem is at fault, cause except
    > for a mistake of my part, blit only test shows that Agg
    > is really the origin of the poor FPS...

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?)

3

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

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.

4

Oups- forgot to include the "light" dynamic example:

#!/usr/bin/env python
"""
An animated image
"""
import sys, time, os, gc
from matplotlib import rcParams
import matplotlib
matplotlib.use("TkAgg")
from matplotlib.matlab import *
import Tkinter as Tk

fig = figure(1)
a = subplot(111)
a = arange(121.0)*2*pi/120.0
dR = 0.1*sin(5*a)
x_0=sin(a)
y_0=cos(a)
line = plot(x_0,y_0)
axis([ -1.5,1.5, -1.5, 1.5 ])

manager = get_current_fig_manager()
cnt = 0
tstart = time.time()
t=0
class loop:
    
    def __init__(self, master):
        self.master = master
        self.updatefig() # start updating
        
    def updatefig(self):
        global t,x_0,y_0, dR, cnt, start,tstart
        t += pi/20
        R=1+sin(t)*dR
        line[0].set_data(R*x_0,R*y_0)
        manager.canvas.draw()
        cnt += 1
        if not cnt%100:
            print 'FPS', 100.0/(time.time() - tstart)
            tstart=time.time()
        self.master.after(1, self.updatefig)

cnt = 0

loop(manager.canvas._tkcanvas)
show()