dynamic update in TkAgg ? (more)

I took out a wristwatch and timed it instead of guessing. I

    > get three frames per second. It's about 4x from where we
    > started, but still slow. I guess I'm just underpowered,
    > although a couple of years ago this was a powerhouse. It
    > seems that matplotlib may not be suited to this task. I
    > don't think it should take 2 GHz just to power a stripchart.

One more comment here, mainly for Todd.

Todd, I get 34 FPS on anim.py with GTKAgg and only 21 FPS with the
anim_tk.py, where both scripts are doing the same thing. The profiler
reveals a good chunk of the time is in

      103 2.300 0.022 2.300 0.022 tkagg.py:4(blit)

This may be a tk limitation, but I just wanted to point it out to you
in case there are any optimizations you can apply to that function.

I'll include the anim_tk.py I'm using for profiling below.

Cheers,
JDH

#!/usr/bin/env python2.3
import matplotlib
matplotlib.use('TkAgg')
import matplotlib.matlab
import Tkinter as Tk
import matplotlib.numerix as numerix

fig = matplotlib.matlab.figure(1)
ind = numerix.arange(60)
x_tmp=
for i in range(100):
    x_tmp.append(numerix.sin((ind+i)*numerix.pi/15.0))

X=numerix.array(x_tmp)
lines = matplotlib.matlab.plot(X[:,0],'o')

manager = matplotlib.matlab.get_current_fig_manager()
def updatefig(*args):
    updatefig.count += 1
    lines[0].set_ydata(X[:,updatefig.count%60])
    manager.canvas.draw()
    return updatefig.count
updatefig.count=-1

manager.show()
import time
tstart = time.time()
while 1:
    cnt = updatefig()
    if cnt==100: break
    
print 'FPS', 100.0/(time.time() - tstart)

John Hunter writes

One more comment here, mainly for Todd.

Todd, I get 34 FPS on anim.py with GTKAgg and only 21 FPS with the
anim_tk.py, where both scripts are doing the same thing. The profiler
reveals a good chunk of the time is in

      103 2.300 0.022 2.300 0.022 tkagg.py:4(blit)

This may be a tk limitation, but I just wanted to point it out to you
in case there are any optimizations you can apply to that function.

I'll include the anim_tk.py I'm using for profiling below.

Cheers,
JDH

I do believe it is a limitation of the tk api (which the
blitting code uses) that makes writing to pixels of the
tk window comparatively slow. It is possible to come up
with a tk interface using tkinter3000( aka wck) and some
hairy code to write directly to the window buffer. Eric
Jones has done this for the chaco implementation. Porting
it to matplotlib would take some work (how much I'm not
quite sure). It is isn't important to us right now so
we aren't going to do it for some time. If someone else
is interested they are welcome to. It does mean writing
a C or C++ implementation for each platform (i.e., X, win32,
aqua). I know that the blitting can be improved by more
than an order of magnitude in this way.

Perry

    > I took out a wristwatch and timed it instead of guessing. I
    > get three frames per second. It's about 4x from where we
    > started, but still slow. I guess I'm just underpowered,
    > although a couple of years ago this was a powerhouse. It
    > seems that matplotlib may not be suited to this task. I
    > don't think it should take 2 GHz just to power a stripchart.

One more comment here, mainly for Todd.

Todd, I get 34 FPS on anim.py with GTKAgg and only 21 FPS with the
anim_tk.py, where both scripts are doing the same thing. The profiler
reveals a good chunk of the time is in

      103 2.300 0.022 2.300 0.022 tkagg.py:4(blit)

This may be a tk limitation, but I just wanted to point it out to you
in case there are any optimizations you can apply to that function.

I tried a few things, but I didn't find anymore performance blunders
so barring the kind of optimization Perry mentioned, I think we're
stuck. I think most of the time is going into Tk_PhotoPutBlock.

I'll include the anim_tk.py I'm using for profiling below.

I only got 11-12 FPS (for tkagg) on a 1.7 Ghz Pentium-IV...

Todd

···

On Fri, 2004-05-28 at 10:56, John Hunter wrote: