Menu
▾
▴
matplotlib-users
|
From: Steve C. <ste...@ya...> - 2005-03-15 09:18:08
|
On Mon, 2005-03-14 at 22:38 -0800, matplotlib-users- re...@li... wrote: > > I am unable to get matplotlib animations to work properly. Some of the data from > > the previous frame is getting included. > > > > I have included some example code that shows this. When draw() is called in the > > loop, it draws the data from the previous frame for y<0.15 (ca), and from the > > current frame for larger y. The final show() does *not* lag even if set_ydata > > has not been called since the last draw(). > > > > This is with version 0.72. Any ideas about what is happening? I ran the script with GTKCairo and it looks fine to me. Perhaps you are using GTKAgg which looks like it has the problem. My guess is that its caused by using gtk.idle_add() which results in asynchronous expose_event updates. Steve |
|
From: Steve C. <ste...@ya...> - 2005-03-15 10:55:05
|
> > I am unable to get matplotlib animations to work properly. Some of the data from > > the previous frame is getting included. I've just fixed it in CVS, it should appear in the next matplotlib version. Or try installing from CVS if you need the fix now, and would like to test it. Steve |
|
From: John H. <jdh...@ac...> - 2005-03-16 15:11:31
|
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
Steve> I ran the script with GTKCairo and it looks fine to me.
Steve> Perhaps you are using GTKAgg which looks like it has the
Steve> problem. My guess is that its caused by using
Steve> gtk.idle_add() which results in asynchronous expose_event
Steve> updates.
I looked at this briefly and am a little confused by something. The
base class FigureCanvasGTK.expose_event has this in the doc string
"""Expose_event for all GTK backends
Should not be overridden.
but then the derived class
class FigureCanvasGTKAgg(FigureCanvasGTK, FigureCanvasAgg):
does in fact override it.
I inserted a debug print statement into
FigureCanvasGTKAgg.expose_event and it is not called until the loop is
over. I think this is because the call to sleep is preventing the
idle handler from ever getting engaged.
Perhaps Joachim would be better off using a gtk timer to handle his
animation. Basically, matplotlib tries to provide a GUI neutral way
to do animation (eg anim.py) but if you want to do something
semi-sophisticated like alter the timing between draws, you should use
the GUI specific functionality for this, eg gtk timers.
Here is an example
# animate increasing terms in fourier expansion of y=x
import pygtk
pygtk.require('2.0')
import gtk
import matplotlib
matplotlib.use('GTKAgg')
from matplotlib.numerix import arange, pi, sin, zeros, Float
import pylab
class Animator:
def __init__(self, samples=1000, max_k=30):
self.samples = samples
self.max_k = max_k
self.fig = pylab.figure()
self.ax = self.fig.add_subplot(111)
x = arange(0.0, 1.0, 1.0/self.samples)
self.s = zeros((self.max_k,samples), Float)
for k in range(1,self.max_k):
self.s[k] = self.s[k-1]+(-1)**(k+1)*sin(pi*x*k)/k
self.line, = self.ax.plot(x, x*1.3, linewidth=1.0)
self.ax.grid(True)
self.k = 1
def draw(self, *args):
self.line.set_ydata(2./pi*self.s[self.k])
self.ax.set_title('k = '+str(self.k))
pylab.draw()
self.k += 1
return self.k<self.max_k
anim = Animator()
gtk.timeout_add(100,anim.draw)
pylab.show()
|
|
From: Joachim B H. <cj...@st...> - 2005-03-16 21:18:45
|
John Hunter <jdh...@ac...> writes: > Perhaps Joachim would be better off using a gtk timer to handle his > animation. Basically, matplotlib tries to provide a GUI neutral way > to do animation (eg anim.py) but if you want to do something > semi-sophisticated like alter the timing between draws, you should > use the GUI specific functionality for this, eg gtk timers. Thanks for the comments and example, John. I'll study it in detail later. For the moment I don't really want to do anything more advanced than anim.py. The sleep() was only there to make the problem obviously visible, but it was also present without it. Longer term, I'd like to be able to pass in a 2d array of y values, and get a window like the one show() presents, only with a "play" button for animation plus a slider or similar to navigate to a specific frame. I don't think this should be too hard, but I don't know python yet so it may take some time. The context is that I want to visualise time evolving partial differential equations. (In general 3d complex-valued ones, but that's a bit too much information to put in one plot.) So I have results from the solver, for each time step, no real-time plotting or anything like that. Cheers, Joachim. |
|
From: Steve C. <ste...@ya...> - 2005-03-17 02:47:16
|
On Wed, 2005-03-16 at 09:00 -0600, John Hunter wrote:
> I looked at this briefly and am a little confused by something. The
> base class FigureCanvasGTK.expose_event has this in the doc string
>
> """Expose_event for all GTK backends
> Should not be overridden.
>
> but then the derived class
>
> class FigureCanvasGTKAgg(FigureCanvasGTK, FigureCanvasAgg):
>
> does in fact override it.
A while ago I started updating the GTK backends to be more consistent
(by using the same draw(), expose_event() etc methods) and also so they
create just one Renderer instance and reuse it for all drawing. I
completed doing this for GTK and GTKCairo. With GTKAgg, it looked a bit
more complicated, and seeing that GTKAgg was already working quite well
I decided to leave it and come back to it later.
So my intention was to have all GTK backends using a standard draw() and
expose_event() from the base class and just have a specific
_renderer_init() to set their own renderer. To make this work by reusing
one Renderer instance I needed to add new methods to each Renderer:
def _set_pixmap(self, pixmap):
def _set_width_height(self, width, height):
which are called by _render_figure().
I still think this approach is a good idea, but it may need to be
modified to allow it to work with GTKAgg.
The patch I committed to CVS does the first part (using standard draw()
and expose()), but not the second part - GTKAgg still uses multiple
Renderer instances.
The patch also fixes another little problem that GTKAgg has. If you
display a figure, then obscure the window and expose the window (without
resizing it), GTKAgg will completely redraw the window, which may give a
flicker in the obscured/exposed area for a complicated figure, whereas
GTK and GTKCairo will redraw the original figure from the double-
buffered memory, which is much faster and flicker-free.
> I inserted a debug print statement into
> FigureCanvasGTKAgg.expose_event and it is not called until the loop is
> over. I think this is because the call to sleep is preventing the
> idle handler from ever getting engaged.
I think Joachim just used the sleep call just to make the problem
obvious, and that the problem is there even if sleep is not called,
except that it may flash so quickly you can not be sure what you saw.
> Perhaps Joachim would be better off using a gtk timer to handle his
> animation. Basically, matplotlib tries to provide a GUI neutral way
> to do animation (eg anim.py) but if you want to do something
> semi-sophisticated like alter the timing between draws, you should use
> the GUI specific functionality for this, eg gtk timers.
>
> Here is an example
> [...]
Thats works OK, but requires that users write their own animation draw()
routines, whereas using double-buffering for GTKAgg makes it available
to all GTKAgg users for free. I think double-buffering is generally what
you want to use for flicker-free drawing, and there does not seem to be
any performance penalty from the few tests I made.
Steve
|
|
From: Steve C. <ste...@ya...> - 2005-03-17 03:14:03
|
On Wed, 2005-03-16 at 16:59 -0800, matplotlib-users- re...@li... wrote: > > Joachim B Haga <cj...@st...> > > writes: > > > > >> You may have something there. I tested different backends: > > >> > > >> These show the problem: While these work fine: > > >> > > >> GtkAgg WX > > >> QtAgg WXAgg > > >> CairoAgg GTK > > >> GtkCairo (yes, really) TkAgg > > > > Forget this list. I just discovered that -d<nonexistentbackend> > > silently defaults to GtkAgg, at least on my install (debian). So the > > "problem" list probably boils down to GtkAgg. Maybe you knew that. John, I've been caught out a few times with this too! I think we should change it so -d<nonexistentbackend> raises an error, what do you think? > > Steve Chaplin <ste...@ya...> writes: > > > I've just fixed it in CVS, it should appear in the next matplotlib > > > version. Or try installing from CVS if you need the fix now, and would > > > like to test it. > > > > Excellent! I'll wait; or, if you want me to test, tell me which file and > > version it is so I can patch my install with the relevant changes. Its the file lib/matplotlib/backends/backend_gtkagg.py version 1.10, it may also need lib/matplotlib/backends/backend_gtk.py version 1.80 Steve |
|
From: John H. <jdh...@ac...> - 2005-03-17 03:29:08
|
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
Steve> John, I've been caught out a few times with this too! I
Steve> think we should change it so -d<nonexistentbackend> raises
Steve> an error, what do you think?
I've been caught many times too. We used t raise on nonexistant
backend strings, but we were rightly yelled at because mpl is a
library, and users often want to pass other -d flags to their
programs, eg -debug. So now it fails silently, which is bad, but may
be better than the alternative of blocking all other -d flags.
One possible solution is to warn, but allow the user to turn off the
warning with an rc param.
I'm inclined to leave it as is though, and deal with it as a annoying
problem. Users who are passing -dBackend flags are probably
sophisticated enough to survive this annoyance. But if you have a
clean solution, I'm open to it.
JDH
|
|
From: Joachim B. H. <c.j...@fy...> - 2005-03-17 11:56:12
|
John Hunter wrote: >>>>>>"Steve" == Steve Chaplin <ste...@ya...> writes: > > Steve> John, I've been caught out a few times with this too! I > Steve> think we should change it so -d<nonexistentbackend> raises > Steve> an error, what do you think? > > I'm inclined to leave it as is though, and deal with it as a annoying > problem. Users who are passing -dBackend flags are probably > sophisticated enough to survive this annoyance. But if you have a > clean solution, I'm open to it. Deprecate -d<backend> and introduce --mpl.backend=<backend>? Perhaps extend to allow overriding all .matplotlibrc directives, so you can do --mpl.verbose.level=debug and so on? I think that would be clean, and if you like the idea I can create a patch for it. But I saw -d mentioned as matlab compatible, so if that is important then maybe not. -j. PS. my excuses for not preserving CCs earlier. |
|
From: Joachim B H. <cj...@st...> - 2005-03-15 10:31:35
|
Steve Chaplin <ste...@ya...>
writes:
> > > I am unable to get matplotlib animations to work properly. Some
> > > of the data from the previous frame is getting included.
> > >
> > > This is with version 0.72. Any ideas about what is happening?
>
> I ran the script with GTKCairo and it looks fine to me.
>
> Perhaps you are using GTKAgg which looks like it has the problem. My
> guess is that its caused by using gtk.idle_add() which results in
> asynchronous expose_event updates.
You may have something there. I tested different backends:
These show the problem: While these work fine:
GtkAgg WX
QtAgg WXAgg
CairoAgg GTK
GtkCairo (yes, really) TkAgg
So for now I'll just switch to WXAgg. It's not as fast but it does the
job. Thanks!
(I'll assist, of course, in further testing if anyone wants to look
into it)
-j.
|
|
From: Joachim B H. <cj...@st...> - 2005-03-16 20:47:57
|
Joachim B Haga <cj...@st...> writes: >> You may have something there. I tested different backends: >> >> These show the problem: While these work fine: >> >> GtkAgg WX >> QtAgg WXAgg >> CairoAgg GTK >> GtkCairo (yes, really) TkAgg Forget this list. I just discovered that -d<nonexistentbackend> silently defaults to GtkAgg, at least on my install (debian). So the "problem" list probably boils down to GtkAgg. Maybe you knew that. Steve Chaplin <ste...@ya...> writes: > I've just fixed it in CVS, it should appear in the next matplotlib > version. Or try installing from CVS if you need the fix now, and would > like to test it. Excellent! I'll wait; or, if you want me to test, tell me which file and version it is so I can patch my install with the relevant changes. Cheers, Joachim. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X