[matplotlib-devel] Buglets in svg backend?
Hi folks, I've just implemented support in ipython for simultaneous use of the interactive mpl gui backends along with inlined figures, as I had suggested to Eric things could work. But I'm seeing two little glitches, illustrated here: http://fperez.org/tmp/mpl_svg_bug.png The white console on the right is IPython, the mpl window was my only open figure. The code I ran was: x=rand(1000) plot (x) # this pops up the normal gui, I tested Qt4Agg and GTKAgg paste() # this pasted the open figure into the IPython console. At this point, the plot in the window got that funny size, with the x-labels double-drawn. It seems as if the figure got re-drawn over the previous canvas, at a different size. If I resize the window, the problem goes away, but if I don't resize it, it persists through new plot/draw operations. The second problem... I then zoomed the interactive window and issued paste again, getting the plot in the bottom right of the figure: paste() And here the bug seems to be related to clipping: while the window clips OK, the SVG seems not to. Is this a fundamental limitation of the SVG backend? For IPython we can also switch to pngs if that turns out to work better, but I figured I'd report these... All this was done with current mpl from trunk. Cheers, f -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Making DreamPie work even better with matplotlib
Hello, I'm the author of DreamPie - a new graphical Python shell ( http://dreampie.sourceforge.net ). I worked to make it work nicely with matplotlib, but I would like to make it work even better. Currently, if you import matplotlib in DreamPie and it is in non-interactive mode, DreamPie suggests that you switch to interactive mode. After you do that, everything works fine, because I made DreamPie support handling events of Tkinter, GTK and QT when it's idle. I thought that it might be even nicer if DreamPie would automatically switch matplotlib to interactive mode when it's detected, instead of asking the user to find the right configuration file and edit it. I asked people at matplotlib-users for their opinion, and Eric Firing said that non-interactive mode is useful when running matplotlib scripts. I looked at http://matplotlib.sourceforge.net/users/shell.html and saw that ipython's pylab mode provides a run command that runs a script in non-interactive mode. I wonder: could such a function be added to the pylab module? Then I think it would be fine if DreamPie automatically switched to interactive mode. (I can write this function if you like) Do you have any other suggestions on how to make DreamPie more matplotlib-friendly? Do you think that after these changes DreamPie can be recommended as a matplotlib-friendly shell? Thanks, Noam -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Multiple redraws in qt4 backend
I was checking the performance of the GtkAgg and Qt4Agg backends and noticed that the Qt4Agg backend calls canvas.draw 3 times for every pylab.show() The three calls are: backend_qt4.py::65 manager.window.show()->resizeEvent->draw backend_qt4.py::71 figManager.canvas.draw() backend_qtagg4.py::69 FigureCanvasQTAgg.paintEvent -> FigureCanvasAgg.draw(self) show() in backend_qt4.py includes the extra call to figManager.canvas.draw compared to the gtk backend. It doesn't seem to be necessary. There is a 'replot' flag in the canvas.draw function in FigureCanvasQTAgg which looks as though it should be True in order to prevent the extra draw in paintEvent. John -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Multiple redraws in qt4 backend
On Tue, Sep 7, 2010 at 10:09 AM, John Porter wrote: > I was checking the performance of the GtkAgg and Qt4Agg backends and noticed > that the Qt4Agg backend calls canvas.draw 3 times for every pylab.show() > The three calls are: > backend_qt4.py::65 > manager.window.show()->resizeEvent->draw > backend_qt4.py::71 > figManager.canvas.draw() > backend_qtagg4.py::69 > FigureCanvasQTAgg.paintEvent -> FigureCanvasAgg.draw(self) > show() in backend_qt4.py includes the extra call to figManager.canvas.draw > compared to the gtk backend. It doesn't seem to be necessary. > There is a 'replot' flag in the canvas.draw function in FigureCanvasQTAgg > which looks as though it should be True in order to prevent the extra draw > in paintEvent. What mpl version are you using? -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] For review and merging: new GUi support for Qt4 and Wx
On 09/03/2010 12:37 PM, Brian Granger wrote: > Hello all, > > I would like to submit the following branch on github for review and > merging into matplotlib trunk: > > http://github.com/ellisonbg/matplotlib/commits/guisupport > > This branch implements the logic needed for the qt4 and wx backends to > fully work with the upcoming IPython 0.11 release. In our testing we > have run many of the mpl examples (including the new animation > examples) in both qt4/wx in both the terminal based IPython and the > new IPython Qt GUI. For background on these changes please see this > thread: > > http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTik2SNtXMaezCc0UiMnCYg6LxwEL1eN9YASnmOua%40mail.gmail.com&forum_name=matplotlib-devel > > It is important to note that we have not updated the other matplotlib > backends (gtk, tk, etc.) to have this logic. This is mainly because > we know almost nothing about these toolkits and could really use some > help from folks who are experts at the respective toolkits. We have > done some minimal testing and these other backends do work for simple > examples in the terminal IPython, but they won't work in all cases and > will definitely not work in the new IPython Qt based GUI. > > We would love feedback and help testing as these changes are > significant (even though only a few lines of code). To test this > stuff you will need to grab the following IPython development branch: > > http://github.com/ipython/ipython/tree/newkernel > > You should be able to run the examples in regular ipython: > > ipython --pylab qt4|wx > > Or the new GUI > > ipythonqt --pylab qt4|wx Brian, Fernando, I have been doing a little testing with ipython 0.10 versus ipython-newkernel, both modes, and with mpl svn versus your guisupport. There are so many possible modes of operation and combinations of versions and backends that all this will take some time to sort out. Can you give me simple examples of what does *not* work correctly when you use mpl *svn* with ipython-newkernel, in either or both of the console or gui modes, but *does* work with your guisupport version? Thanks. Eric > > Cheers, > > Brian > -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] For review and merging: new GUi support for Qt4 and Wx
Hi Eric, On Tue, Sep 7, 2010 at 1:31 PM, Eric Firing wrote: > > I have been doing a little testing with ipython 0.10 versus > ipython-newkernel, both modes, and with mpl svn versus your guisupport. > There are so many possible modes of operation and combinations of > versions and backends that all this will take some time to sort out. > > Can you give me simple examples of what does *not* work correctly when > you use mpl *svn* with ipython-newkernel, in either or both of the > console or gui modes, but *does* work with your guisupport version? Thanks for your testing, Eric. With matplotlib *alone*, I can't find a way to crash/lock/whatever the combo of matplotlib(svn)+ipython-newkernel. The reason, i believe, is that guisupport.py is available in ipython itself, and it goes out of its way to avoid creating a second main qt app, letting matplotlib create it. Since that main app is alive all the time, there's only one app and one event loop and life is good. But if I were to open another library that uses Qt and makes a new main qApp unconditionally, we'd have problems. Brian and Evan have recently just added the guisupport.py patch to Enthought's ETS, so that now it probably will be pretty hard to actually see the problem: if both ipython and ets go out of their way to avoid the nested main app issue, mpl can get away with making one unconditionally and things will probably work OK. But the idea is for all of us (ipython, ets, mpl, etc) to agree on a collaborative protocol with a simple api: check for one special '_in_event_loop' flag in the main toolkit before making one. That will make it easier to have interactive code that uses Wx or Qt from more than one library coexisting in the same process. I'll let Brian fill in with more details when he has some availability, but I think that's the gist of it. Regards, f -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] For review and merging: new GUi support for Qt4 and Wx
On 09/07/2010 11:07 AM, Fernando Perez wrote: > Hi Eric, > > On Tue, Sep 7, 2010 at 1:31 PM, Eric Firing wrote: >> >> I have been doing a little testing with ipython 0.10 versus >> ipython-newkernel, both modes, and with mpl svn versus your guisupport. >> There are so many possible modes of operation and combinations of >> versions and backends that all this will take some time to sort out. >> >> Can you give me simple examples of what does *not* work correctly when >> you use mpl *svn* with ipython-newkernel, in either or both of the >> console or gui modes, but *does* work with your guisupport version? > > Thanks for your testing, Eric. > > With matplotlib *alone*, I can't find a way to crash/lock/whatever the > combo of matplotlib(svn)+ipython-newkernel. > > The reason, i believe, is that guisupport.py is available in ipython > itself, and it goes out of its way to avoid creating a second main qt > app, letting matplotlib create it. Since that main app is alive all > the time, there's only one app and one event loop and life is good. > But if I were to open another library that uses Qt and makes a new > main qApp unconditionally, we'd have problems. > > Brian and Evan have recently just added the guisupport.py patch to > Enthought's ETS, so that now it probably will be pretty hard to > actually see the problem: if both ipython and ets go out of their way > to avoid the nested main app issue, mpl can get away with making one > unconditionally and things will probably work OK. > > But the idea is for all of us (ipython, ets, mpl, etc) to agree on a > collaborative protocol with a simple api: check for one special > '_in_event_loop' flag in the main toolkit before making one. That > will make it easier to have interactive code that uses Wx or Qt from > more than one library coexisting in the same process. Fernando, There are two parts to guisupport: ensure a single main app, and ensure no more than one call to the mainloop. The first makes perfect sense, and cannot cause any problems that I can see. The second one is the one that I think may be both unnecessary and undesirable. The reason is that the gui toolkit mainloop functions or methods are designed for nested calls. This permits blocking within a running mainloop, and allows show() to block when pyplot is not in interactive mode. This is what is lost with the guisupport mods. Some changes to mainloop logic may well be needed, but I don't think that prohibiting nested calls to the underlying toolkit mainloop function is necessary or desirable. Eric > > I'll let Brian fill in with more details when he has some > availability, but I think that's the gist of it. > > Regards, > > f -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
