MatPlotLib Figure Freezing on Windows

[dmikkili]

Python version: 2.7; Windows version: 7; Matplotlib version 1.2.1

I'm making an interactive plot (set with plt.ion()) while some other parts of my script do some calculations, and I update the plot frequently with calls to plt.draw(). I noticed that when I click the figure window of the interactively drawn plot and try to move it around, the figure stops updating and Windows tags the process "Not Responding", but the script continues to run without a problem. If I don't click the figure window, everything is ok.

I've read that some people have had this issue before on other forums and they got around the problem by using different backends, but my computer doesn't respond differently to other backends. What can I do?

[bmorris3]

HI all, I'm debugging with @dmikkili . I've found that a short example script that duplicates this issue on his machine is this:

from matplotlib import pyplot as plt
import time

plt.ion()
fig = plt.figure()
axis = fig.add_subplot(111)

for i in range(30000):
    axis.plot(i,i,'o')
    plt.draw()
    if i > 5:
        time.sleep(2)   ## On Windows, a pause is needed to be able to click the figure at all
plt.close()

This replicates the same mpl calls that we make in the much longer script where the issue occurs. I do not have any problems moving around the figure produced by this script as it changes on Mac OS X 10.6, Python 2.7, mpl 1.2.1.

[dmcdougall]

@cgohlke Can you reproduce this?

[cgohlke]

I can reproduce this with matplotlib-1.3.0rc4.

[mdboom]

Which backend are you using, and does trying an alternative make any difference?

[bmorris3]

My default backend is "MacOSX" (and I do not get the error).

[mdboom]

Some data points. On Linux, TkAgg works, GtkAgg stops responding (but continues to update), Qt4Agg never displays at all, and WxAgg (being Gtk under the hood) stops responding (but continues to update).

[mdboom]

Do we know which backend on Windows is failing, though?

[cgohlke]

On Windows, all GUI backends are failing: TkAgg, WxAgg, GTKAgg, Qt4Agg. Qt4Agg does not display anything, the others are unresponsive.

[bmorris3]

Hi all, I'm still having this issue. Are you guys? @dmikkili

[dmikkili]

Yes I am still having this error. I am using WxAgg by the way. Is there a solution/workaround for this issue?

[efiring]

This is not a mode of operation that we have ever supported; on some backends, on some platforms (Mike noted TkAgg on Linux) one can get away with it, but this is an accident, not something designed into mpl. Interactive mode is designed to work with ipython. That's all. The longstanding decision to delegate this to ipython could be revisited, but I suspect that no matter what we do, there will be problems with some environments.

The documentation, http://matplotlib.org/users/shell.html, might need some more work to clarify the situation. Part of the problem might be the distinction between working interactively from a shell, and having a script that updates a plot based on calculations.

Here is a modification of the example script above that I think will work with any interactive backend. Note that "ion()" is not needed--it is irrelevant here.

import matplotlib
matplotlib.use("qt4agg")
from matplotlib import pyplot as plt

fig = plt.figure()
axis = fig.add_subplot(111)

for i in range(30000):
    axis.plot(i,i,'o')
    if i > 5:
        plt.pause(1)
plt.close()

This probably is not what you really want, though; I suspect you want long-running calculations combined with nicely-behaved interactive plots. The problem is that the window will not be responding to events (e.g., resize) during those calculations, unless you do them in a separate process, or a separate thread, or unless you sprinkle plt.pause(0.001) liberally throughout your calculation code to force gui event processing.

Generally, the pyplot interface is not suitable for this sort of thing; it is better to drop down to the object-oriented layer.

[dmikkili]

I tried the modified script you wrote with the WXAgg backend, and it worked like a charm. You are right though, we did want to do if for long running calculations, and when i implemented it like the example above it was still freezing. I did however manage to get it to not freeze by just adding plt.pause(1) in my for loop to pause between the interactive updates to the plot. That managed to do the trick. I understand though that it isnt the best and will need to rely on something other than pyplot in the future for doing this sort of work. Thanks for all the help.

[mdboom]

@efiring: So, at the end of the day, should we close this issue? I think reorganizing it to not rely so much on IPython is worthy of a MEP in and of itself. (I could make a MEP placeholder for it, so we don't lose track).

[efiring]

@mdboom: I am happy to close it. As for a MEP: given all the backends and possible environments and circumstances in which they might be used, I think we should be cautious about trying to make all combinations work. A good first step would be some perhaps brief improvements in the documentation that we could point to when questions arise. A second step would be a concise single description of the problems to be solved. Then we might be able to see where progress can be made without getting ourselves lost in the GUI mess.

[bmorris3]

@efiring Would you mind pointing me to some documentation that explains what you mean when you say "Generally, the pyplot interface is not suitable for this sort of thing; it is better to drop down to the object-oriented layer." What is the "object-oriented layer"?

[tacaswell]

@bmorris3
http://matplotlib.org/faq/usage_faq.html#general-concepts

http://www.aosabook.org/en/matplotlib.html

http://matplotlib.org/api/index.html

[bmorris3]

Thanks for the informative links @tacaswell , but I don't see how they helps to make sense of @efiring 's comment.

[efiring]

@bmorris3
In GUI programming, there needs to be one master that keeps track of all the parts and runs the mainloop which responds to events via callbacks. Pyplot provides this functionality, in cooperation with ipython. When one tries to embed pyplot code in an external gui program, however (which I think is what the OP was doing), the external program needs to be the master. The clean solution to this potential conflict (battling masters) is to use the lower-level, non-pyplot part of mpl--the object-oriented component library, and let the real master, the top-level gui program, handle all parts explicitly.

[WeatherGod]

Another way to look at it is that the different GUI back ends are GUI
programs in their own rights, just a very stripped down one. These GUI back
ends play the same role that any GUI you would use for embedding. Pyplot
makes this "embedding" into the back end guis completely painless and
hidden from the user.

So, the OO layer is a deeper layer in matplotlib that gives complete
control to the user, at the sacrifice of convenience.

I hope that helps!
Ben Root

[keon]

for anyone find this link on google, (which i did)
http://stackoverflow.com/questions/3441874/matplotlib-animation-either-freezes-after-a-few-frames-or-just-doesnt-work

link above will help