Re: [Matplotlib-users] scipy.xplt to matplotlib

[Arnd B. <arn...@we...>]

On Mon, 30 May 2005, John Hunter wrote:

> >>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:

There is another point:
For me the y-axis label does not show up in Fernando's example.

Changing the end of the code to:
##############################
raw_input("before x-label")
pylab.xlabel('Time t[s]')
raw_input("after x-label, before y-label")
pylab.ylabel('Response')
raw_input("after y-label")
#####################
shows that the xlabel is shown after the pylab.ylabel line
and the ylabel is never shown.
This is on debian linux, python 2.3, matplotlib.__version__ 0.80

>     Fernando> One word of caution: you'll notice that in the above,
>     Fernando> the xplt script runs very fast, while the mpl one is
>     Fernando> unacceptably slow (and it consumes a TON of cpu).  There
>     Fernando> may be a trick to provide acceptable update speeds for
>     Fernando> dynamically resized plots, but unfortunately I don't use
>     Fernando> that kind of plotting much, so I can't really offer much
>     Fernando> help there.
>
> Yes, this will run extremely slow, because each plot command creates a
> new matplotlib.lines.Line2D object, which at draw time means a new
> transformation, a new graphics context, etc.  By the time you reach
> the end of the loop, you'll have a ton of extra overhead in object
> creation and function calls.
>
> If possible, I suggest creating just two line objects and manipulating
> their data directly, as in
>
> from math import sin, cos
> import matplotlib.numerix as nx
> import pylab
> pylab.ion()  # interactive on, so each plot updates the window
>
> pylab.hold('on')
> allt = [0]          # grow these lists and set the line data with them
> allsin = [sin(0)]
> allcos = [cos(0)]
> lsin, = pylab.plot(allt, allsin, 'g+') # lsin is a Line2D instance
> lcos, = pylab.plot(allt, allcos, 'ro') # lcos is a Line2D instance
> pylab.xlabel('Time t[s]')
> pylab.ylabel('Response')
> pylab.axis([0,10,-1,1])
> for t in nx.arange(0.1,10,0.1):
>     allt.append(t)
>     allsin.append(sin(t))
>     allcos.append(cos(t))
>     lsin.set_data(allt, allsin)
>     lcos.set_data(allt, allcos)
>     pylab.draw()
>
> # to prevent the window from closing
> raw_input()
>
>     Fernando> I get the feeling that there's an O(N^2) problem
>     Fernando> somewhere in there, because it seems to me that the plot
>     Fernando> update slows down worse than linearly as more points are
>     Fernando> added.  But I didn't really measure it, it's just a gut
>     Fernando> feeling.
>
> This will still be slower than xplt, but shouldn't be mind-numbingly
> slow.

On my machine it is slower by a factor 15
(import matplotlib ; matplotlib.rc.func_globals["get_backend"]()
gives 'GTKAgg').

As I am a speed fanatic ;-) I would surely like this
to be faster. But one should not forget
that matplotlib does quite a lot
(in particular antialising, sophisticated markers etc.).

> I have some concrete ideas on how to make animation faster, and
> have started working on them, but don't have anything ready yet.

That sounds great - looking very much forward to this!
Would this also result in a shorter code for the matplotlib example
(which is at the moment more than twice as long
than the scipy.xplt one)?

Best,

Arnd