Repository navigation
Unresponsive figure when using interactive mode on Windows #3052
Description
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.
Activity
tacaswell commentedon May 8, 2014
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 commentedon May 8, 2014
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 commentedon May 10, 2014
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 commentedon May 28, 2014
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 commentedon May 28, 2014
@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
%matplotlibwhich 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 commentedon May 28, 2014
@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
%matplotlibsolves this issue with interactive mode and QT without having to play withrepaintand 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 commentedon May 28, 2014
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 commentedon May 28, 2014
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 commentedon May 28, 2014
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 commentedon Nov 30, 2014
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 commentedon Nov 30, 2014
@jonathanhex, have you tried using ipython, starting with the
%matplotlib'magic'?jonathanhex commentedon Dec 1, 2014
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 commentedon Dec 1, 2014
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:
tacaswell commentedon Dec 2, 2014
I think we have to be careful about what we mean by interactive. I think the term can fairly mean
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 commentedon Dec 2, 2014
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 commentedon Dec 2, 2014
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:
efiring commentedon Dec 2, 2014
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 commentedon Dec 2, 2014
Wow this looks like it solved it, I had my interpreter set up incorrectly. Thanks a lot for the help!