Unresponsive figure when using interactive mode on Windows

[natezb]

I am using Windows running Python 2.7.5 (and IPython 1.1.0) with Matplotlib 1.3.1, using the Qt4Agg backend. When I run

import matplotlib.pyplot as plt
plt.ion()
plt.plot([1, 2, 3])

a (blank) figure window is immediately opened and is unresponsive ("loading" cursor on mouseover, can't move window, etc.). This happens in both Python and IPython, and whether I import MPL directly or via pylab.

If I call plt.pause(2), the plot itself is drawn and the figure window can be moved, but it may be moved only until the pause command expires. It seems that dragging the window causes the pause to last longer, i.e. the GUI main loop seems to be blocking the 'countdown' from happening.

If I omit the plt.ion() and call plt.show(), a figure with a plot is shown as expected.

Strangely, when using a Python 2.7.5 interpreter embedded in Spyder (a scientific python IDE), interactive mode works as expected. If I run the startup script provided by Spyder (scientific_startup.py) in Python or IPython, it does not fix the issue, so I'm unsure where this difference in behavior is coming from. All three interpreters use the 'Qt4Agg' backend.

[tacaswell]

Can you see if this still persists on master? This may be addressed by #2844 / #2559 (I do not have a windows box to test on).

[natezb]

I will test it as soon as I can get matplotlib to build from source. It's been more challenging than anticipated so far...

[natezb]

Good news! I finally got MPL to build successfully despite some mysterious issues.

You are right that the bug seems to be fixed... mostly. The plot is now drawn correctly and its window is responsive. The interactive prompt stays alive and further calls to plt.plot() are drawn as expected.

However, the prompt becomes quite laggy. Characters appear one at a time, a significant fraction of a second after they are typed. This lag persists even after the figure is closed.

[HamsterHuey]

This may not be related to your issue, but I have replicated a similar issue in my Python installation via Anaconda (on Windows 8/7). In my case, I was able to determine that the issue lies with the Anaconda installation only supporting the QT backend for matplotlib and not TKAgg. For some reason, interactive mode does not want to work with QT/Pyside on Windows (I found others posting with similar issues).

I then installed WinPython, where the TKAgg backend works correctly. In the WinPython Python shell, I was able to get interactive mode to work as expected.

As you report, IPython and Spyder seem to somehow fix the issue with interactive plotting using the QT backend, but I'm not sure what they are doing to get interactive plotting to work with the QTAgg backend on Windows.

[tacaswell]

@Tillsten I have you in my head as the local windows expert, can you take a look at this?

@natezb Sorry, I did not notice your update. Are you using ipython or the stock python shell? if you are using ipython try %matplotlib which does, as it is named, some magic related to threading.

@HamsterHuey The conclusion from #2844 seems to be that something with the event/repaint loop in qt on windows is screwy.

[HamsterHuey]

@tacaswell Yes, I saw that and that seems to be a QT specific issue so it seems to be consistent with what I observed (that Matplotlib with the QT backend which is the only option with the Anaconda Matplotlib install has this issue with interactive mode). With the WinPython install, since it uses the TkAgg backend by default, this issue does not pop up when using interactive mode.

It is interesting that IPython via %matplotlib solves this issue with interactive mode and QT without having to play with repaint and this seems like this is due to the threading implemented in IPython. Is it possible to eventually implement something like that natively in matplotlib for windows or does this type of fix have to be specifically on the python shell side?

[Tillsten]

While i can't reproduce the behavior from the first post, i can reproduce the laggy console behavior. Looking at some old issues (qt, ipython and matplotlib have a long history with laggy keyboard input.) and the ipython source, i think there is no simple solution to the problem.

Ipythons matplotlib magic jumps through a lot of hoops to interact with the qt-eventloop, it even manages the eventloop by itself instead of just starting it, maybe one of ipython-devs knows more, also @efiring seems to have experience with qt and laggy consoles.

Spyder works because it uses a buffer to communicate with the python process and keypresses are recorded by qt itself.

[efiring]

Regarding Anaconda: I haven't tried it on Windows, but on a Mac one can install the Anaconda wxpython package; then the mpl wxagg backend is available.

[efiring]

Going back to the original post, I conclude that what is reported is normal. Mpl has never promised to provide full interactivity; that has always been delegated to ipython. As gui libraries have evolved, it has sometimes been possible to have interactivity without ipython's %matplotlib mode; but when this occurs it is just a bonus.

[jonathanhex]

Hi,

I'm having a similar problem as described earlier, using python shell 2.7.6 and TkAgg backend. I understand from the last post that working in interactive mode isn't promised, but if it is possible to resolve it, it would incredibly helpful to me.

[efiring]

@jonathanhex, have you tried using ipython, starting with the %matplotlib 'magic'?

[jonathanhex]

No... I'm running Python 2.7.6 from Pyscripter. I read what you wrote about "Mpl has never promised to provide full interactivity; that has always been delegated to ipython." But it is very important to me to continue working using my current configuration. Is there any possibility that could be accomplished? Thanks!

[WeatherGod]

I think I am going to disagree with @efiring 's assertion, somewhat. Full
interactivity was always intended for ipython (matplotlib was originally a
patch to ipython), but that doesn't mean that even basic interactive
functionality should be completely ignored. Something seems fishy here.

On Mon, Dec 1, 2014 at 4:59 PM, jonathanhex notifications@github.com
wrote:

No... I'm running Python 2.7.6 from Pyscripter. I read what you wrote
about "Mpl has never promised to provide full interactivity; that has
always been delegated to ipython." But it is very important to me to
continue working using my current configuration. Is there any possibility
that could be accomplished? Thanks!

—
Reply to this email directly or view it on GitHub
#3052 (comment)
.

[tacaswell]

I think we have to be careful about what we mean by interactive. I think the term can fairly mean

• programatically updating a graph (animation, live data)
• pan/zoom
• full clicky-clicky UI
• extracting data from clicks to drive analysis (ex skimage widgets)

The main commonality here is that the UI responds to the user poking it with a mouse and to do that the GUI framework must have an event loop running to process the mouse/keyboard events.

The set up and management of the integration of the event loop with the REPL is what we have delegated to IPython or IDEs (most modern ones in fact just use IPython). Full embeddings of mpl in to larger GUI applications just use the application event loop running for the interface which is simpler.

I would suggest you report this as a bug to pyscripter, but the project looks pretty dead (last commit was in 2012). I would try to match which ever gui-frame work it uses and hope that you can piggyback on the IDE's GUI's event loop.

[jonathanhex]

tacaswell , Thanks for your response, I will check with the Pyscripter project as well.
I was wondering if you have any suggestions as to how I can pinpoint the root of the problem - Pyscripter or MPL?
Do you have any ideas for workarounds that could possibly work? Could multithreading work?

[WeatherGod]

I hadn't realized it, but yeah, the problem is that pyscripter is its own
GUI. When doing a straight-out plt.ion() and such, matplotlib is then
trying to start up its own GUI app and kick off the mainloop. Most GUI
toolkits are not amenable to this configuration and multi-threading
wouldn't fix the problem. ipython addresses the issue by managing the
backends in a careful way so that new apps are not created and collide with
an existing mainloop (gross simplification).

I haven't tried this, but one possible workaround is to choose a backend
that is completely independent of the GUI toolkit that pyscripter is using.
So, if it is using gtk, then use qt4agg as your backend or vice-versa. Note
that some GUIs are actually wrappers around other GUIs in some environments
(such as WX wrapping GTK).
This is all just theory based on my newly created understanding of
matplotlib interactivity.

On Tue, Dec 2, 2014 at 3:32 PM, jonathanhex notifications@github.com
wrote:

tacaswell , Thanks for your response, I will check with the Pyscripter
project as well.
I was wondering if you have any suggestions as to how I can pinpoint the
root of the problem - Pyscripter or MPL?
Do you have any ideas for workarounds that could possibly work? Could
multithreading work?

—
Reply to this email directly or view it on GitHub
#3052 (comment)
.

[efiring]

https://code.google.com/p/pyscripter/wiki/FAQ#How_do_I_use_Matplotlib_with_PyScripter_?
@jonathanhex did the instructions above work with an earlier version? Do they fail now?
As @WeatherGod noted, pyscripter looks thoroughly dead, with no perceptible activity since mid-2012 apart from googlecode issue submissions. I suspect you are stuck with whatever limitations it has now, and will eventually have to find a substitute, unless developers come forward to revive the project. Complex gui apps like this have to be maintained.

[jonathanhex]

Wow this looks like it solved it, I had my interpreter set up incorrectly. Thanks a lot for the help!