matplotlib-devel Mailing List for matplotlib

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:

    Gregory> You are right, I should definitely install pygtk on my
    Gregory> system to check that, I wonder how a 3X increase in FPS
    Gregory> is possible: after all, de-activating blit in the TkAgg
    Gregory> produce only a 1.5X increase (and no image of course ;-)

The gtk advantage over tk depends on the example.  For images (eg
for Andrew's dynamic image) the advantage is approx 1.5x.  For the
simple line drawing dyanmic example you posted, it's about 3x.  I
suppose the difference is that in the image example, there is a much
larger, shared computational burden in agg, whereas with the simple
line drawing example the blitting difference is more pronounced.

    Gregory> It could be more important for GTKAgg, if it is closer to
    Gregory> raw Agg speed than TkAgg and FltkAgg...Something to test
    Gregory> would be to use the Agg backend without exporting the
    Gregory> pixmap buffer but doing the drawing, and check how many
    Gregory> draw/second one can have on the examples, to really check
    Gregory> the penalty associated to the different toolkits, and the
    Gregory> maximum gain we can have by reusing Agg buffer instead of
    Gregory> creating one for each draw...Is this doable?

I'm certainly happy to try it.  One last thing you may want to do
before sending in your updates tomorrow is to run backend_driver.py in
the examples subdir to make sure your changes don't create any
problems with the known examples.

    Gregory> In these cases nothing performance wise, in fact the way
    Gregory> you use should me marginally faster (avoiding the
    Gregory> creation/destruction of python buffer objects ).  Python
    Gregory> buffer objects is a way for me to implement the transfer
    Gregory> without copy of the Agg buffer to fltk in more "abstract"
    Gregory> way: no need to implement a c extension that know both
    Gregory> the internals of agg and fltk, I split it using the
    Gregory> python buffer as a standard protocol (buffer objects were
    Gregory> intended for just this use, I think...).  This is not
    Gregory> very important, but it could simplify things if there is
    Gregory> multiple renderer and multiple toolkits to bind...like if
    Gregory> alternative to Agg is implemented (or multiple version of
    Gregory> Agg must be supported)...and I guess that the overhead of
    Gregory> this creation/destruction of python buffer objects is
    Gregory> really negligeable.

Another area it may help is in backend_gtk and backend_wx, which *do*
use string methods to access the agg image buffer.

JDH

> > You are right, I should definitely install pygtk on my 
> system to check 
> > that, I wonder how a 3X increase in FPS is possible: after all, 
> > de-activating blit in the TkAgg produce only a 1.5X 
> increase (and no 
> > image of course ;-) ): something else than Agg must hold Tk 
> (and Fltk) 
> > back then: I have to test the FPS one have without Agg drawing and 
> > blitting, only canvas update, with GTK, Tk and Fltk, to be sure...
> > 
> I guess I'm surprised at that. How are you disabling the 
> blit? If no blit is being done, where else is the time going 
> if not for agg?

In the draw method of the FigureCanvasTkAgg class (in
matplotlib/backends/backend_tkagg.py file), I just commented out the
second line, going from:

def draw(self):
        FigureCanvasAgg.draw(self)
        tkagg.blit(self._tkphoto, self.renderer._renderer, 2)
        self._master.update_idletasks()


To:


def draw(self):
        FigureCanvasAgg.draw(self)
        #tkagg.blit(self._tkphoto, self.renderer._renderer, 2)
        self._master.update_idletasks()

This makes the image dissapear from screen of course, but still draw the
image in the in-memory Agg buffer...and ask the Tk canvas to redraw
itself (allways with the same empty image), I guess...so I indeed
suspect that the Tk canvas updating is causing the slow down somehow...I
will check that tomorrow for sure! 

Greg, puzzled too ;-)

Though I suppose it may simply be in the mechanism that
tk uses to update it's own buffer (it does its own blitting
behind the scenes as I understand it)... 

> 
> You are right, I should definitely install pygtk on my system to check
> that, I wonder how a 3X increase in FPS is possible: after all,
> de-activating blit in the TkAgg produce only a 1.5X increase (and no
> image of course ;-) ): something else than Agg must hold Tk (and Fltk)
> back then: I have to test the FPS one have without Agg drawing and
> blitting, only canvas update, with GTK, Tk and Fltk, to be sure...
> 
I guess I'm surprised at that. How are you disabling the blit?
If no blit is being done, where else is the time going if not
for agg?

Puzzled, Perry

> I didn't see where the optimization was helping - could you 
> clarify? It looks like about a 5% for tkagg and there are no 
> comparisons for the fltkagg with "classic vs optimized"
> 
>   Classic TkAgg: 9.98 FPS
>   Improved TkAgg: 10.6 FPS
>   FltkAgg: 16.7 FPS

I will check the non optimized (ie with no reuse of Agg buffers) FltkAgg
backend tomorrow, but you are right, the improvement are reproductible
but small. The change for reusing buffer is trivial though, and it may
help if there is memory leak...
 
> As you may know, blitting in tk is pretty slow and there 
> doesn't appear to be anything we can do about it short of 
> some platform dependent extension code (which might be worth 
> doing at some point for linux and win32).  With your example 
> I get approx 14 FPS with tkagg on my system and 45 FPS with 
> gtkagg.  My point is that unless there are some fundamental 
> limitations in fltk as there are in tk, you might want to 
> look to gtkagg as a performance benchmark rather than tkagg. 
> gtkagg is typically 3x faster than tkagg for dynamic plots.

You are right, I should definitely install pygtk on my system to check
that, I wonder how a 3X increase in FPS is possible: after all,
de-activating blit in the TkAgg produce only a 1.5X increase (and no
image of course ;-) ): something else than Agg must hold Tk (and Fltk)
back then: I have to test the FPS one have without Agg drawing and
blitting, only canvas update, with GTK, Tk and Fltk, to be sure...

> Please send them in, either to the list or directly to Todd 
> and myself.  Todd will be interested in anything pertaining 
> to tkagg.

Ok, I send the complete relevant files as attachement tomorrow, to you
and Todd.

> I understand the rational behind not creating a 
> new agg buffer object with each draw, but at the same time 
> your numbers seem to suggest that it isn't too important, 
> performance wise.
It could be more important for GTKAgg, if it is closer to raw Agg speed
than TkAgg and FltkAgg...Something to test would be to use the Agg
backend without exporting the pixmap buffer but doing the drawing, and
check how many draw/second one can have on the examples, to really check
the penalty associated to the different toolkits, and the maximum gain
we can have by reusing Agg buffer instead of creating one for each
draw...Is this doable?

> Also, I am not sure about the necessity of 
> creating a python buffer object - perhaps you can explain 
> this a bit more.  tkagg and gtkagg both use the agg rendering 
> buffer directly with no string copy, eg
> 
>   RendererAgg* aggRenderer = static_cast<RendererAgg*>(args[1].ptr());
> 
> 
> 
> //gtk
> 
>     gdk_draw_rgb_32_image(drawable, gc, 0, 0, 
> 			  width, 
> 			  height, 
> 			  GDK_RGB_DITHER_NORMAL,
> 			  aggRenderer->pixBuffer,
> 			  width*4);
> // tk
>     block.pixelPtr =  aggRenderer->pixBuffer;
> 
> where pixBuffer is the agg pixel buffer.
> 
> What does exposing the buffer in the python layer buy you?

In these cases nothing performance wise, in fact the way you use should
me marginally faster (avoiding the creation/destruction of python buffer
objects ). 
Python buffer objects is a way for me to implement the transfer without
copy of the Agg buffer to fltk in more "abstract" way: no need to
implement a c extension that know both the internals of agg and fltk, I
split it using the python buffer as a standard protocol (buffer objects
were intended for just this use, I think...). 
This is not very important, but it could simplify things if there is
multiple renderer and multiple toolkits to bind...like if alternative to
Agg is implemented (or multiple version of Agg must be supported)...and
I guess that the overhead of this creation/destruction of python buffer
objects is really negligeable.

Best regards,

Greg.

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:

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

I didn't see where the optimization was helping - could you clarify?
It looks like about a 5% for tkagg and there are no comparisons for
the fltkagg with "classic vs optimized"

  Classic TkAgg: 9.98 FPS
  Improved TkAgg: 10.6 FPS
  FltkAgg: 16.7 FPS

As you may know, blitting in tk is pretty slow and there doesn't
appear to be anything we can do about it short of some platform
dependent extension code (which might be worth doing at some point for
linux and win32).  With your example I get approx 14 FPS with tkagg on
my system and 45 FPS with gtkagg.  My point is that unless there are
some fundamental limitations in fltk as there are in tk, you might
want to look to gtkagg as a performance benchmark rather than tkagg.
gtkagg is typically 3x faster than tkagg for dynamic plots.

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

Please send them in, either to the list or directly to Todd and
myself.  Todd will be interested in anything pertaining to tkagg.  I
understand the rational behind not creating a new agg buffer object
with each draw, but at the same time your numbers seem to suggest that
it isn't too important, performance wise.  Also, I am not sure about
the necessity of creating a python buffer object - perhaps you can
explain this a bit more.  tkagg and gtkagg both use the agg rendering
buffer directly with no string copy, eg

  RendererAgg* aggRenderer = static_cast<RendererAgg*>(args[1].ptr());



//gtk

    gdk_draw_rgb_32_image(drawable, gc, 0, 0, 
			  width, 
			  height, 
			  GDK_RGB_DITHER_NORMAL,
			  aggRenderer->pixBuffer,
			  width*4);
// tk
    block.pixelPtr =  aggRenderer->pixBuffer;

where pixBuffer is the agg pixel buffer.

What does exposing the buffer in the python layer buy you?

It is best (for me) for you to submit your changes as complete files
so I can merge / compare with ediff; my dev tree is often out of sync
with the non-devel cvs tree so applying diffs is hard.

Thanks!
JDH

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

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.

On Thu, 2004-07-15 at 10:25, John Hunter wrote:
> >>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:
> 
>     Gregory>   It seems thus that Agg drawing is the main limiting
>     Gregory> factor here, all the tricks to avoid using strings (or
>     Gregory> reallocating Agg renderer, for that matter) are not too
>     Gregory> usefull...  What I do not understand is why I got such
>     Gregory> low values, compared to the 4 or 10 FPS: I guess, given
>     Gregory> the impact of Agg drawing, all the *Agg backends should
>     Gregory> have about the same speed...Is there something I miss
>     Gregory> here?  My workstation is not current top of class, but
>     Gregory> it's a PIV 2.3 GHz, so certainly not slow either...I do
>     Gregory> not think the graphic subsystem is at fault, cause except
>     Gregory> for a mistake of my part, blit only test shows that Agg
>     Gregory> 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?)

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

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:

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

Hi, 
I try to benchmark some modif I did to speed up Agg rendering
(basically, avoid re-creation of an Agg renderer if draw is called
without changing previous fig size and DPI)...
To do so, I changed the dynamic_image demo to use TkAgg (except my fltk
backend, it's the only one working on my workstation for the moment, I
do not have Wx not GTK).
First tests shows no improvement :-(, but in fact I can not reproduce
the speed mentioned when you discussed this demo (4 FPS or 10 FPS), only
got 0.9 FPS.

I thus tryed to check why I got such slow animation, and the results are
as follow (I use the current CVS matplotlib, with numarray):

  Example with no drawing (manager.canvas.draw commented out in the
updatefig method) : stabilize around 50 FPS, this is the best we can
hope using numarray which is, I think, the only limitting factor in this
case)...

  Example with call to tkagg.blit but no Agg canvas drawing (done
replacing the draw method in FigureCanvasTkAgg, see below * ): stabilize
around 19 FPS

  * old draw:
   def draw(self): 
      FigureCanvasAgg.draw(self)
      tkagg.blit(self._tkphoto,self.renderer._renderer, 2)
      self._master.update_idletasks()
    new version:
   def draw(self): 
      try:      
	   tkagg.blit(self._tkphoto,self.renderer._renderer, 2)
      except:
         FigureCanvasAgg.draw(self)
         tkagg.blit(self._tkphoto,self.renderer._renderer, 2)
      self._master.update_idletasks()
 
  Example with Agg canvas drawing + blitting: (normal TkAgg backend):
    stabilize around 1 FPS

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

Any idea about this? 

Thanks,

Best regards,

Greg.

----
Dynamic_image_tkagg.py
----
#!/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)
x = arange(120.0)*2*pi/120.0
x = resize(x, (100,120))
y = arange(100.0)*2*pi/100.0
y = resize(y, (120,100))
y = transpose(y)
z = sin(x) + cos(y)
im = a.imshow( z, cmap=cm.jet)#, interpolation='nearest')


manager = get_current_fig_manager()
cnt = 0
tstart = time.time()

class loop:
    
    def __init__(self, master):
        self.master = master
        self.updatefig() # start updating
        
    def updatefig(self):
        global x, y, cnt, start
        x += pi/15
        y += pi/20
        z = sin(x) + cos(y)
        im.set_array(z)
        manager.canvas.draw()
        cnt += 1
        if not cnt%20:
            print 'FPS', cnt/(time.time() - tstart)
        self.master.after(1, self.updatefig) 

cnt = 0

loop(manager.canvas._tkcanvas)
show()