Hi all, I'm posting to report two bugs in 'backend_qt4.py' with the latest PyQt release: (see eventually the attached test script) (1) in class 'NavigationToolbar2QT' l. 285-300 : I had to replace '.svg' by '.png' for all the icons to be displayed correctly on the navigation toolbar (only one was already loaded in the right file format). (2) I still experience slow performance of pan/zoom feature with the latest PyQt release (the last release for which I had no problem is the 4.3.3 release). You'll find attached a simple test script: with PyQt 4.3.3 pan/zoom is real-time, and with PyQt 4.4.3 it's really slower (in fact, zooming and panning are happening at the right speed but after a short delay from the mouse click) Regards, Pierre Raybaut
Hi Pierre, On Saturday 16 August 2008 03:08:49 am Pierre Raybaut wrote: > Hi all, > > I'm posting to report two bugs in 'backend_qt4.py' with the latest PyQt > release: > (see eventually the attached test script) > > (1) in class 'NavigationToolbar2QT' l. 285-300 : I had to replace '.svg' > by '.png' for all the icons to be displayed correctly on the navigation > toolbar (only one was already loaded in the right file format). Could this be a problem with your installation of Qt4? I have been using the svg icons for a while now, without any issues. In what way are they displayed incorrectly? Did you compile qt4 without svg support? > (2) I still experience slow performance of pan/zoom feature with the > latest PyQt release (the last release for which I had no problem is the > 4.3.3 release). You'll find attached a simple test script: with PyQt > 4.3.3 pan/zoom is real-time, and with PyQt 4.4.3 it's really slower (in > fact, zooming and panning are happening at the right speed but after a > short delay from the mouse click) I think I need a more quantitative test script that proves this is an issue with mpl before I can be of help. On my machine, panning and zooming is just as fast with your test script as it is with a simple test plot in pylab using either the qt4agg or gtkagg backends. I have qt-4.4.1 and PyQt4-4.4.2 installed. Is there anyway you can profile the poor performance you are seeing? Darren
Hi Darren, 2008年8月18日 Darren Dale <dsd...@gm...>: >> (1) in class 'NavigationToolbar2QT' l. 285-300 : I had to replace '.svg' >> by '.png' for all the icons to be displayed correctly on the navigation >> toolbar (only one was already loaded in the right file format). > > Could this be a problem with your installation of Qt4? I have been using the I really don't know, I'll have to check this. I really thought it was a bug because the icons aren't all in the same format as if they were partially replaced from svg to png for example, so I didn't think it could come from my installation. But I'll check my installation. > svg icons for a while now, without any issues. In what way are they displayed > incorrectly? They are not displayed at all. > Did you compile qt4 without svg support? I use the official PyQt binaries, so yes, I guess. > >> (2) I still experience slow performance of pan/zoom feature with the >> latest PyQt release (the last release for which I had no problem is the >> 4.3.3 release). You'll find attached a simple test script: with PyQt >> 4.3.3 pan/zoom is real-time, and with PyQt 4.4.3 it's really slower (in >> fact, zooming and panning are happening at the right speed but after a >> short delay from the mouse click) > > I think I need a more quantitative test script that proves this is an issue > with mpl before I can be of help. On my machine, panning and zooming is just > as fast with your test script as it is with a simple test plot in pylab using > either the qt4agg or gtkagg backends. I have qt-4.4.1 and PyQt4-4.4.2 > installed. Is there anyway you can profile the poor performance you are > seeing? Is your machine under Windows? If you need something to prove that this has nothing to do with my machine or my software, I can tell you that there is exactly the same bug on a virtual machine, after a clean Windows XP install, and using only the official Python MSI installer and the official PyQt installer (and the latest matplotlib release of course). I also saw the same bug on three other machines, but the real proof is the VM. So I will take a look again at the 'backend_qt4.py' source code to see if there is a way to profile this poor performance. Thanks Pierre > > Darren > >
On Monday 18 August 2008 09:33:47 Pierre Raybaut wrote: > Hi Darren, > > 2008年8月18日 Darren Dale <dsd...@gm...>: > >> (1) in class 'NavigationToolbar2QT' l. 285-300 : I had to replace '.svg' > >> by '.png' for all the icons to be displayed correctly on the navigation > >> toolbar (only one was already loaded in the right file format). > > > > Could this be a problem with your installation of Qt4? I have been using > > the > > I really don't know, I'll have to check this. I really thought it was > a bug because the icons aren't all in the same format as if they were > partially replaced from svg to png for example, so I didn't think it > could come from my installation. But I'll check my installation. > > > svg icons for a while now, without any issues. In what way are they > > displayed incorrectly? > > They are not displayed at all. > > > Did you compile qt4 without svg support? > > I use the official PyQt binaries, so yes, I guess. I forgot to mention, the svg icons display fine for me with windows xp, matplotlib-0.98.
On Monday 18 August 2008 09:33:47 am Pierre Raybaut wrote: > Hi Darren, > > 2008年8月18日 Darren Dale <dsd...@gm...>: > >> (1) in class 'NavigationToolbar2QT' l. 285-300 : I had to replace '.svg' > >> by '.png' for all the icons to be displayed correctly on the navigation > >> toolbar (only one was already loaded in the right file format). > > > > Could this be a problem with your installation of Qt4? I have been using > > the > > I really don't know, I'll have to check this. I really thought it was > a bug because the icons aren't all in the same format as if they were > partially replaced from svg to png for example, so I didn't think it > could come from my installation. But I'll check my installation. As of version 4.2, Qt supports svg icons. I'll check this on a windows computer tonight, if there is an issue on windows, I guess we'll have to go back to pngs. > > svg icons for a while now, without any issues. In what way are they > > displayed incorrectly? > > They are not displayed at all. > > > Did you compile qt4 without svg support? > > I use the official PyQt binaries, so yes, I guess. > > >> (2) I still experience slow performance of pan/zoom feature with the > >> latest PyQt release (the last release for which I had no problem is the > >> 4.3.3 release). You'll find attached a simple test script: with PyQt > >> 4.3.3 pan/zoom is real-time, and with PyQt 4.4.3 it's really slower (in > >> fact, zooming and panning are happening at the right speed but after a > >> short delay from the mouse click) > > > > I think I need a more quantitative test script that proves this is an > > issue with mpl before I can be of help. On my machine, panning and > > zooming is just as fast with your test script as it is with a simple test > > plot in pylab using either the qt4agg or gtkagg backends. I have qt-4.4.1 > > and PyQt4-4.4.2 installed. Is there anyway you can profile the poor > > performance you are seeing? > > Is your machine under Windows? No. > If you need something to prove that this has nothing to do with my > machine or my software, I can tell you that there is exactly the same > bug on a virtual machine, after a clean Windows XP install, and using > only the official Python MSI installer and the official PyQt installer > (and the latest matplotlib release of course). I also saw the same bug > on three other machines, but the real proof is the VM. I'm not familiar with virtual machines, so I guess I dont understand what that proves. I'm looking for something that indicates this is an issue with matplotlib and not Qt. You found a problem once you upgraded from 4.3.3, but I have not seen a similar problem. I'll try running your test script on a windows machine tonight, but in the meantime, perhaps you could try to determine if there is a step in backend_qt4agg.FigureCanvasQTAgg.paintEvent (or somewhere else) that is the source of the bottleneck. > So I will take a look again at the 'backend_qt4.py' source code to see > if there is a way to profile this poor performance. Thanks, that would be helpful. Darren
Darren Dale a écrit : >> If you need something to prove that this has nothing to do with my >> machine or my software, I can tell you that there is exactly the same >> bug on a virtual machine, after a clean Windows XP install, and using >> only the official Python MSI installer and the official PyQt installer >> (and the latest matplotlib release of course). I also saw the same bug >> on three other machines, but the real proof is the VM. >> > > I'm not familiar with virtual machines, so I guess I dont understand what that > proves. I'm looking for something that indicates this is an issue with > matplotlib and not Qt. You found a problem once you upgraded from 4.3.3, but > I have not seen a similar problem. I'll try running your test script on a > I've just received another proof (I know that it does not solve the problem, but I'm feeling less lonely!): a canadian Python/Qt user experienced exactly the same bug (and he did the test on three different machines, two with XP and one with Vista). > windows machine tonight, but in the meantime, perhaps you could try to > determine if there is a step in backend_qt4agg.FigureCanvasQTAgg.paintEvent > (or somewhere else) that is the source of the bottleneck. > What do you mean exactly? Pierre
On Monday 18 August 2008 16:17:03 Pierre Raybaut wrote: > Darren Dale a écrit : > >> If you need something to prove that this has nothing to do with my > >> machine or my software, I can tell you that there is exactly the same > >> bug on a virtual machine, after a clean Windows XP install, and using > >> only the official Python MSI installer and the official PyQt installer > >> (and the latest matplotlib release of course). I also saw the same bug > >> on three other machines, but the real proof is the VM. > > > > I'm not familiar with virtual machines, so I guess I dont understand what > > that proves. I'm looking for something that indicates this is an issue > > with matplotlib and not Qt. You found a problem once you upgraded from > > 4.3.3, but I have not seen a similar problem. I'll try running your test > > script on a > > I've just received another proof (I know that it does not solve the > problem, but I'm feeling less lonely!): a canadian Python/Qt user > experienced exactly the same bug (and he did the test on three different > machines, two with XP and one with Vista). > > > windows machine tonight, but in the meantime, perhaps you could try to > > determine if there is a step in > > backend_qt4agg.FigureCanvasQTAgg.paintEvent (or somewhere else) that is > > the source of the bottleneck. > > What do you mean exactly? Nevermind. It turns out its not exactly poor performance, but for some reason the gui events were not getting processed as frequently on windows. Maybe Qt changed something in an attempt to optimize performance. I applied a patch in svn 6043, but its a really simple fix. At the end of backend_qt4agg.FigureCanvasQTAgg.draw, after self.update(), add this line: QtGui.qApp.processEvents() It seemed to improve things on my windows laptop, but let me know if it fixes the problem for you. Darren
We're in the process of converting our documentation from doxygen (parsing C++ and post processing w/ many huge regexp's to make it look like python) to using sphinx. I was curious about the equation formatting extension that you guys wrote and how it compares to the one (or is it two?) that come with sphinx. What didn't work about the sphinx math extensions that caused you to write a new one? Are there any plans to incorporate some of the MPL extensions into sphinx? We'll definitely need latex equations, testing of examples (maybe some combination of the MPL plot and doctest like functions), and inheritance diagrams so we might just use the MPL sphinx extensions for these. We're also planning on making some custom html templates to make our output more like doxygen (especially having a class summary showing all the methods at the top of the screen). We may also look at processing our users guide, our python module, matplotlib, python, and any other 3rd party package we install that uses sphinx (and maybe some that don't) to create a single set of docs showing all the python modules we deliver that has a common look to it. Thanks, Ted
Ted Drain wrote: > We're in the process of converting our documentation from doxygen (parsing C++ and post processing w/ many huge regexp's to make it look like python) to using sphinx. I was curious about the equation formatting extension that you guys wrote and how it compares to the one (or is it two?) that come with sphinx. Sphinx can a) use jsmath to render math directly in the browser, b) use latex/dvipng to generate images that are included in the HTML. Matplotlib's mplmath extension uses matplotlib itself to generate images of the math to include in the HTML. All of them have pros and cons, mostly related to environment/installation concerns. The extensions are generally interchangable (you should be able to use any one of them on the same reST source code), however the mplmath extension is currently lagging behind the Sphinx ones in some optional features at the moment. But our goal is to try to not break compatibility with the Sphinx built-in ones so they remain interchangeable. > What didn't work about the sphinx math extensions that caused you to write a new one? When we wrote ours, a Sphinx math extension didn't exist. Also, for us, generating math expressions using our own system is a form of regression testing. > Are there any plans to incorporate some of the MPL extensions into sphinx? > We've submitted all of our generally useful ones to Sphinx. For math, Sphinx decided to go another way (which makes sense to avoid a dependency on matplotlib). The inheritance diagram submission seems to have stalled -- there are a few people with slightly different views on the problem creating a bit of a logjam, but I don't think it's insurmountable. Lastly, the ipython syntax-highlighting work we did is in Pygments repository and primed for the next release. > We'll definitely need latex equations, testing of examples (maybe some combination of the MPL plot and doctest like functions), and inheritance diagrams so we might just use the MPL sphinx extensions for these. > > We're also planning on making some custom html templates to make our output more like doxygen (especially having a class summary showing all the methods at the top of the screen). We may also look at processing our users guide, our python module, matplotlib, python, and any other 3rd party package we install that uses sphinx (and maybe some that don't) to create a single set of docs showing all the python modules we deliver that has a common look to it. > I'd like to hear about your experiences doing this kind of integration work. It's something we all want more of. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
Mike, Thanks for the info. I noticed in plot_directive.py that ipython seems to be required to build the docs. Is that absolutely needed or is it a holdover from doing something else? I'm asking because we would like to build the docs locally but don't currently install ipython. I could change that but it's just an artifact of something else it might be better to remove that dependency. Ted > -----Original Message----- > From: Michael Droettboom [mailto:md...@st...] > Sent: Thursday, September 11, 2008 5:50 AM > To: Ted Drain > Cc: mat...@li... > Subject: Re: [matplotlib-devel] Question about sphinx doc extensions > > Ted Drain wrote: > > We're in the process of converting our documentation from doxygen > (parsing C++ and post processing w/ many huge regexp's to make it look > like python) to using sphinx. I was curious about the equation > formatting extension that you guys wrote and how it compares to the one > (or is it two?) that come with sphinx. > Sphinx can a) use jsmath to render math directly in the browser, b) use > latex/dvipng to generate images that are included in the HTML. > Matplotlib's mplmath extension uses matplotlib itself to generate > images > of the math to include in the HTML. All of them have pros and cons, > mostly related to environment/installation concerns. The extensions > are > generally interchangable (you should be able to use any one of them on > the same reST source code), however the mplmath extension is currently > lagging behind the Sphinx ones in some optional features at the moment. > But our goal is to try to not break compatibility with the Sphinx > built-in ones so they remain interchangeable. > > What didn't work about the sphinx math extensions that caused you > to write a new one? > When we wrote ours, a Sphinx math extension didn't exist. Also, for > us, > generating math expressions using our own system is a form of > regression > testing. > > Are there any plans to incorporate some of the MPL extensions into > sphinx? > > > We've submitted all of our generally useful ones to Sphinx. For math, > Sphinx decided to go another way (which makes sense to avoid a > dependency on matplotlib). > > The inheritance diagram submission seems to have stalled -- there are a > few people with slightly different views on the problem creating a bit > of a logjam, but I don't think it's insurmountable. > > Lastly, the ipython syntax-highlighting work we did is in Pygments > repository and primed for the next release. > > We'll definitely need latex equations, testing of examples (maybe > some combination of the MPL plot and doctest like functions), and > inheritance diagrams so we might just use the MPL sphinx extensions for > these. > > > > We're also planning on making some custom html templates to make our > output more like doxygen (especially having a class summary showing all > the methods at the top of the screen). We may also look at processing > our users guide, our python module, matplotlib, python, and any other > 3rd party package we install that uses sphinx (and maybe some that > don't) to create a single set of docs showing all the python modules we > deliver that has a common look to it. > > > I'd like to hear about your experiences doing this kind of integration > work. It's something we all want more of. > > Cheers, > Mike > > -- > Michael Droettboom > Science Software Branch > Operations and Engineering Division > Space Telescope Science Institute > Operated by AURA for NASA > > Checked by AVG - http://www.avg.com > Version: 8.0.169 / Virus Database: 270.6.20/1666 - Release Date: > 9/11/2008 7:03 AM
On Thu, Sep 11, 2008 at 5:49 PM, Ted Drain <ted...@jp...> wrote: > Mike, > Thanks for the info. I noticed in plot_directive.py that ipython seems to > be required to build the docs. Is that absolutely needed or is it a > holdover from doing something else? I'm asking because we would like to > build the docs locally but don't currently install ipython. I could change > that but it's just an artifact of something else it might be better to > remove that dependency. I replaced the ipython shell magic_run functionality with the basic code.InteractiveConsole.runsource function. This works fine -- we may lose some of ipython's nice traceback functionality so if we want we can have a switch that uses ipython if available and falls back on the default code module, but for now I have simply removed the ipython dependency. For some reason runsource prints the intro docstring to the console from files passed to runsource -- not sure how suppress this but it is a minor nuisance. JDH
I can't seem to find a link to the new (and wonderful) sphinx docs from the MPL homepage. Are you deliberately waiting to make them "prime"?
I don't understand. With py-2.6, are things more responsive or is there an extremely noticeable lag? On Mon, Aug 31, 2009 at 11:51 AM, william ratcliff<wil...@gm...> wrote: > Ok, I upgraded to python 2.6, installed mpl 0.99 qt 4.5, and the new pyqt > and things are more responsive...However, the difference between having that > line in and taking it out are the difference between having pan/zoom events > being extremely responsive and having an extremely noticeable lag. I've > attached a test file from the web which is rather simple. You can notice > the lag if you either try to pan/zoom using the toolbar, or if you try to > use the slider to change the sizes of the horizontal bars. > > Sigh, upgrading everything to 2.6 is going to be a chore... > > > Thanks, > William > > On Mon, Aug 31, 2009 at 11:30 AM, Darren Dale <dsd...@gm...> wrote: >> >> I've been using 2.6. It should be fine on windows now, but I can't >> attest to it since I only use windows when I have to test and make >> windows installers. >> >> On Mon, Aug 31, 2009 at 10:02 AM, william >> ratcliff<wil...@gm...> wrote: >> > Let me try to upgrade to PyQt 4.5--I'm currently using 4.4.3 on vista 32 >> > bit. Btw. are you using python 2.6 or 2.5 (I ask because I'm still on >> > 2.5 >> > and am wondering if anyone has noticed any difficulties with 2.6). >> > >> > Cheers, >> > Wiliam >> > >> > On Mon, Aug 31, 2009 at 9:36 AM, Darren Dale <dsd...@gm...> wrote: >> >> >> >> Hi William, >> >> >> >> On Mon, Aug 31, 2009 at 8:25 AM, william >> >> ratcliff<wil...@gm...> wrote: >> >> > Hi! I just installed matplotlib version .99 (windows vista, >> >> > python25, >> >> > 32bit) and found that >> >> > this line was missing: >> >> > QtGui.qApp.processEvents() >> >> > >> >> > Adding it sped the QT4Agg backend back to reasonable speeds--but it >> >> > still >> >> > seems a bit slow. Otherwise, I am using the excellent Python(x,y) >> >> > 2.1.14 >> >> > release for my python distribution on this machine. Could this line >> >> > be >> >> > added back? >> >> >> >> Unfortunately, no, that line can not be added back in. When that line >> >> is in place, the backend attempts to process queued events before it >> >> is finished processing the current event. It was leading to segfaults >> >> in some cases. processEvents should not be called in the middle of >> >> processing an event. >> >> >> >> I tested the responsiveness of panning and zooming with and without >> >> that call to processEvents, on Linux and windows and it looked fine. >> >> Maybe its an issue related to a specific Qt version on windows. Things >> >> looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista. >> >> >> >> Darren >> > >> > >> >> >> >> -- >> "In our description of nature, the purpose is not to disclose the real >> essence of the phenomena but only to track down, so far as it is >> possible, relations between the manifold aspects of our experience" - >> Niels Bohr >> >> "It is a bad habit of physicists to take their most successful >> abstractions to be real properties of our world." - N. David Mermin >> >> "Once we have granted that any physical theory is essentially only a >> model for the world of experience, we must renounce all hope of >> finding anything like the correct theory ... simply because the >> totality of experience is never accessible to us." - Hugh Everett III > > -- "In our description of nature, the purpose is not to disclose the real essence of the phenomena but only to track down, so far as it is possible, relations between the manifold aspects of our experience" - Niels Bohr "It is a bad habit of physicists to take their most successful abstractions to be real properties of our world." - N. David Mermin "Once we have granted that any physical theory is essentially only a model for the world of experience, we must renounce all hope of finding anything like the correct theory ... simply because the totality of experience is never accessible to us." - Hugh Everett III
Things are more responsive than with python 2.5 and with qt 4.4.3, but the lag is still noticeable--especially compared to with the addition of the line. On Mon, Aug 31, 2009 at 12:05 PM, Darren Dale <dsd...@gm...> wrote: > I don't understand. With py-2.6, are things more responsive or is > there an extremely noticeable lag? > > On Mon, Aug 31, 2009 at 11:51 AM, william > ratcliff<wil...@gm...> wrote: > > Ok, I upgraded to python 2.6, installed mpl 0.99 qt 4.5, and the new pyqt > > and things are more responsive...However, the difference between having > that > > line in and taking it out are the difference between having pan/zoom > events > > being extremely responsive and having an extremely noticeable lag. I've > > attached a test file from the web which is rather simple. You can notice > > the lag if you either try to pan/zoom using the toolbar, or if you try to > > use the slider to change the sizes of the horizontal bars. > > > > Sigh, upgrading everything to 2.6 is going to be a chore... > > > > > > Thanks, > > William > > > > On Mon, Aug 31, 2009 at 11:30 AM, Darren Dale <dsd...@gm...> > wrote: > >> > >> I've been using 2.6. It should be fine on windows now, but I can't > >> attest to it since I only use windows when I have to test and make > >> windows installers. > >> > >> On Mon, Aug 31, 2009 at 10:02 AM, william > >> ratcliff<wil...@gm...> wrote: > >> > Let me try to upgrade to PyQt 4.5--I'm currently using 4.4.3 on vista > 32 > >> > bit. Btw. are you using python 2.6 or 2.5 (I ask because I'm still on > >> > 2.5 > >> > and am wondering if anyone has noticed any difficulties with 2.6). > >> > > >> > Cheers, > >> > Wiliam > >> > > >> > On Mon, Aug 31, 2009 at 9:36 AM, Darren Dale <dsd...@gm...> > wrote: > >> >> > >> >> Hi William, > >> >> > >> >> On Mon, Aug 31, 2009 at 8:25 AM, william > >> >> ratcliff<wil...@gm...> wrote: > >> >> > Hi! I just installed matplotlib version .99 (windows vista, > >> >> > python25, > >> >> > 32bit) and found that > >> >> > this line was missing: > >> >> > QtGui.qApp.processEvents() > >> >> > > >> >> > Adding it sped the QT4Agg backend back to reasonable speeds--but it > >> >> > still > >> >> > seems a bit slow. Otherwise, I am using the excellent Python(x,y) > >> >> > 2.1.14 > >> >> > release for my python distribution on this machine. Could this > line > >> >> > be > >> >> > added back? > >> >> > >> >> Unfortunately, no, that line can not be added back in. When that line > >> >> is in place, the backend attempts to process queued events before it > >> >> is finished processing the current event. It was leading to segfaults > >> >> in some cases. processEvents should not be called in the middle of > >> >> processing an event. > >> >> > >> >> I tested the responsiveness of panning and zooming with and without > >> >> that call to processEvents, on Linux and windows and it looked fine. > >> >> Maybe its an issue related to a specific Qt version on windows. > Things > >> >> looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista. > >> >> > >> >> Darren > >> > > >> > > >> > >> > >> > >> -- > >> "In our description of nature, the purpose is not to disclose the real > >> essence of the phenomena but only to track down, so far as it is > >> possible, relations between the manifold aspects of our experience" - > >> Niels Bohr > >> > >> "It is a bad habit of physicists to take their most successful > >> abstractions to be real properties of our world." - N. David Mermin > >> > >> "Once we have granted that any physical theory is essentially only a > >> model for the world of experience, we must renounce all hope of > >> finding anything like the correct theory ... simply because the > >> totality of experience is never accessible to us." - Hugh Everett III > > > > > > > > -- > "In our description of nature, the purpose is not to disclose the real > essence of the phenomena but only to track down, so far as it is > possible, relations between the manifold aspects of our experience" - > Niels Bohr > > "It is a bad habit of physicists to take their most successful > abstractions to be real properties of our world." - N. David Mermin > > "Once we have granted that any physical theory is essentially only a > model for the world of experience, we must renounce all hope of > finding anything like the correct theory ... simply because the > totality of experience is never accessible to us." - Hugh Everett III >
Hi Darren, 2008年8月18日 Darren Dale <dsd...@gm...>: > Nevermind. It turns out its not exactly poor performance, but for some reason > the gui events were not getting processed as frequently on windows. Maybe Qt > changed something in an attempt to optimize performance. > > I applied a patch in svn 6043, but its a really simple fix. At the end of > backend_qt4agg.FigureCanvasQTAgg.draw, after self.update(), add this line: > > QtGui.qApp.processEvents() > > It seemed to improve things on my windows laptop, but let me know if it fixes > the problem for you. Good work Darren, thanks, it works perfectly! That is great news because I found (and reported) this bug three months ago, so I was beginning to worry about the future of Qt4 backend. Now I can consider updating PyQt in Python(x,y). > I forgot to mention, the svg icons display fine for me with windows xp, > matplotlib-0.98. Forget about it, I've just found out that this is related to one of my own-made packages. Thanks Pierre
Hi! I just installed matplotlib version .99 (windows vista, python25, 32bit) and found that this line was missing: QtGui.qApp.processEvents() Adding it sped the QT4Agg backend back to reasonable speeds--but it still seems a bit slow. Otherwise, I am using the excellent Python(x,y) 2.1.14 release for my python distribution on this machine. Could this line be added back? Cheers, William On Tue, Aug 19, 2008 at 4:58 AM, Pierre Raybaut <co...@py...>wrote: > Hi Darren, > > 2008年8月18日 Darren Dale <dsd...@gm...>: > > Nevermind. It turns out its not exactly poor performance, but for some > reason > > the gui events were not getting processed as frequently on windows. Maybe > Qt > > changed something in an attempt to optimize performance. > > > > I applied a patch in svn 6043, but its a really simple fix. At the end of > > backend_qt4agg.FigureCanvasQTAgg.draw, after self.update(), add this > line: > > > > QtGui.qApp.processEvents() > > > > It seemed to improve things on my windows laptop, but let me know if it > fixes > > the problem for you. > > Good work Darren, thanks, it works perfectly! > That is great news because I found (and reported) this bug three > months ago, so I was beginning to worry about the future of Qt4 > backend. > Now I can consider updating PyQt in Python(x,y). > > > I forgot to mention, the svg icons display fine for me with windows xp, > > matplotlib-0.98. > > Forget about it, I've just found out that this is related to one of my > own-made packages. > > Thanks > Pierre > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
Hi William, On Mon, Aug 31, 2009 at 8:25 AM, william ratcliff<wil...@gm...> wrote: > Hi! I just installed matplotlib version .99 (windows vista, python25, > 32bit) and found that > this line was missing: > QtGui.qApp.processEvents() > > Adding it sped the QT4Agg backend back to reasonable speeds--but it still > seems a bit slow. Otherwise, I am using the excellent Python(x,y) 2.1.14 > release for my python distribution on this machine. Could this line be > added back? Unfortunately, no, that line can not be added back in. When that line is in place, the backend attempts to process queued events before it is finished processing the current event. It was leading to segfaults in some cases. processEvents should not be called in the middle of processing an event. I tested the responsiveness of panning and zooming with and without that call to processEvents, on Linux and windows and it looked fine. Maybe its an issue related to a specific Qt version on windows. Things looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista. Darren
Let me try to upgrade to PyQt 4.5--I'm currently using 4.4.3 on vista 32 bit. Btw. are you using python 2.6 or 2.5 (I ask because I'm still on 2.5 and am wondering if anyone has noticed any difficulties with 2.6). Cheers, Wiliam On Mon, Aug 31, 2009 at 9:36 AM, Darren Dale <dsd...@gm...> wrote: > Hi William, > > On Mon, Aug 31, 2009 at 8:25 AM, william > ratcliff<wil...@gm...> wrote: > > Hi! I just installed matplotlib version .99 (windows vista, python25, > > 32bit) and found that > > this line was missing: > > QtGui.qApp.processEvents() > > > > Adding it sped the QT4Agg backend back to reasonable speeds--but it still > > seems a bit slow. Otherwise, I am using the excellent Python(x,y) 2.1.14 > > release for my python distribution on this machine. Could this line be > > added back? > > Unfortunately, no, that line can not be added back in. When that line > is in place, the backend attempts to process queued events before it > is finished processing the current event. It was leading to segfaults > in some cases. processEvents should not be called in the middle of > processing an event. > > I tested the responsiveness of panning and zooming with and without > that call to processEvents, on Linux and windows and it looked fine. > Maybe its an issue related to a specific Qt version on windows. Things > looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista. > > Darren >
I've been using 2.6. It should be fine on windows now, but I can't attest to it since I only use windows when I have to test and make windows installers. On Mon, Aug 31, 2009 at 10:02 AM, william ratcliff<wil...@gm...> wrote: > Let me try to upgrade to PyQt 4.5--I'm currently using 4.4.3 on vista 32 > bit. Btw. are you using python 2.6 or 2.5 (I ask because I'm still on 2.5 > and am wondering if anyone has noticed any difficulties with 2.6). > > Cheers, > Wiliam > > On Mon, Aug 31, 2009 at 9:36 AM, Darren Dale <dsd...@gm...> wrote: >> >> Hi William, >> >> On Mon, Aug 31, 2009 at 8:25 AM, william >> ratcliff<wil...@gm...> wrote: >> > Hi! I just installed matplotlib version .99 (windows vista, python25, >> > 32bit) and found that >> > this line was missing: >> > QtGui.qApp.processEvents() >> > >> > Adding it sped the QT4Agg backend back to reasonable speeds--but it >> > still >> > seems a bit slow. Otherwise, I am using the excellent Python(x,y) >> > 2.1.14 >> > release for my python distribution on this machine. Could this line be >> > added back? >> >> Unfortunately, no, that line can not be added back in. When that line >> is in place, the backend attempts to process queued events before it >> is finished processing the current event. It was leading to segfaults >> in some cases. processEvents should not be called in the middle of >> processing an event. >> >> I tested the responsiveness of panning and zooming with and without >> that call to processEvents, on Linux and windows and it looked fine. >> Maybe its an issue related to a specific Qt version on windows. Things >> looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista. >> >> Darren > > -- "In our description of nature, the purpose is not to disclose the real essence of the phenomena but only to track down, so far as it is possible, relations between the manifold aspects of our experience" - Niels Bohr "It is a bad habit of physicists to take their most successful abstractions to be real properties of our world." - N. David Mermin "Once we have granted that any physical theory is essentially only a model for the world of experience, we must renounce all hope of finding anything like the correct theory ... simply because the totality of experience is never accessible to us." - Hugh Everett III
"""
This demo demonstrates how to embed a matplotlib (mpl) plot
into a PyQt4 GUI application, including:
* Using the navigation toolbar
* Adding data to the plot
* Dynamically modifying the plot's properties
* Processing mpl events
* Saving the plot to a file from a menu
The main goal is to serve as a basis for developing rich PyQt GUI
applications featuring mpl plots (using the mpl OO API).
Eli Bendersky (el...@gm...)
License: this code is in the public domain
Last modified: 19.01.2009
"""
import sys, os, random
from PyQt4.QtCore import *
from PyQt4.QtGui import *
import matplotlib
from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg as FigureCanvas
from matplotlib.backends.backend_qt4agg import NavigationToolbar2QTAgg as NavigationToolbar
from matplotlib.figure import Figure
class AppForm(QMainWindow):
def __init__(self, parent=None):
QMainWindow.__init__(self, parent)
self.setWindowTitle('Demo: PyQt with matplotlib')
self.create_menu()
self.create_main_frame()
self.create_status_bar()
self.textbox.setText('1 2 3 4')
self.on_draw()
def save_plot(self):
file_choices = "PNG (*.png)|*.png"
path = unicode(QFileDialog.getSaveFileName(self,
'Save file', '',
file_choices))
if path:
self.canvas.print_figure(path, dpi=self.dpi)
self.statusBar().showMessage('Saved to %s' % path, 2000)
def on_about(self):
msg = """ A demo of using PyQt with matplotlib:
* Use the matplotlib navigation bar
* Add values to the text box and press Enter (or click "Draw")
* Show or hide the grid
* Drag the slider to modify the width of the bars
* Save the plot to a file using the File menu
* Click on a bar to receive an informative message
"""
QMessageBox.about(self, "About the demo", msg.strip())
def on_pick(self, event):
# The event received here is of the type
# matplotlib.backend_bases.PickEvent
#
# It carries lots of information, of which we're using
# only a small amount here.
#
box_points = event.artist.get_bbox().get_points()
msg = "You've clicked on a bar with coords:\n %s" % box_points
QMessageBox.information(self, "Click!", msg)
def on_draw(self):
""" Redraws the figure
"""
str = unicode(self.textbox.text())
self.data = map(int, str.split())
x = range(len(self.data))
# clear the axes and redraw the plot anew
#
self.axes.clear()
self.axes.grid(self.grid_cb.isChecked())
self.axes.bar(
left=x,
height=self.data,
width=self.slider.value() / 100.0,
align='center',
alpha=0.44,
picker=5)
self.canvas.draw()
def create_main_frame(self):
self.main_frame = QWidget()
# Create the mpl Figure and FigCanvas objects.
# 5x4 inches, 100 dots-per-inch
#
self.dpi = 100
self.fig = Figure((5.0, 4.0), dpi=self.dpi)
self.canvas = FigureCanvas(self.fig)
self.canvas.setParent(self.main_frame)
# Since we have only one plot, we can use add_axes
# instead of add_subplot, but then the subplot
# configuration tool in the navigation toolbar wouldn't
# work.
#
self.axes = self.fig.add_subplot(111)
# Bind the 'pick' event for clicking on one of the bars
#
self.canvas.mpl_connect('pick_event', self.on_pick)
# Create the navigation toolbar, tied to the canvas
#
self.mpl_toolbar = NavigationToolbar(self.canvas, self.main_frame)
# Other GUI controls
#
self.textbox = QLineEdit()
self.textbox.setMinimumWidth(200)
self.connect(self.textbox, SIGNAL('editingFinished ()'), self.on_draw)
self.draw_button = QPushButton("&Draw")
self.connect(self.draw_button, SIGNAL('clicked()'), self.on_draw)
self.grid_cb = QCheckBox("Show &Grid")
self.grid_cb.setChecked(False)
self.connect(self.grid_cb, SIGNAL('stateChanged(int)'), self.on_draw)
slider_label = QLabel('Bar width (%):')
self.slider = QSlider(Qt.Horizontal)
self.slider.setRange(1, 100)
self.slider.setValue(20)
self.slider.setTracking(True)
self.slider.setTickPosition(QSlider.TicksBothSides)
self.connect(self.slider, SIGNAL('valueChanged(int)'), self.on_draw)
#
# Layout with box sizers
#
hbox = QHBoxLayout()
for w in [ self.textbox, self.draw_button, self.grid_cb,
slider_label, self.slider]:
hbox.addWidget(w)
hbox.setAlignment(w, Qt.AlignVCenter)
vbox = QVBoxLayout()
vbox.addWidget(self.canvas)
vbox.addWidget(self.mpl_toolbar)
vbox.addLayout(hbox)
self.main_frame.setLayout(vbox)
self.setCentralWidget(self.main_frame)
def create_status_bar(self):
self.status_text = QLabel("This is a demo")
self.statusBar().addWidget(self.status_text, 1)
def create_menu(self):
self.file_menu = self.menuBar().addMenu("&File")
load_file_action = self.create_action("&Save plot",
shortcut="Ctrl+S", slot=self.save_plot,
tip="Save the plot")
quit_action = self.create_action("&Quit", slot=self.close,
shortcut="Ctrl+Q", tip="Close the application")
self.add_actions(self.file_menu,
(load_file_action, None, quit_action))
self.help_menu = self.menuBar().addMenu("&Help")
about_action = self.create_action("&About",
shortcut='F1', slot=self.on_about,
tip='About the demo')
self.add_actions(self.help_menu, (about_action,))
def add_actions(self, target, actions):
for action in actions:
if action is None:
target.addSeparator()
else:
target.addAction(action)
def create_action( self, text, slot=None, shortcut=None,
icon=None, tip=None, checkable=False,
signal="triggered()"):
action = QAction(text, self)
if icon is not None:
action.setIcon(QIcon(":/%s.png" % icon))
if shortcut is not None:
action.setShortcut(shortcut)
if tip is not None:
action.setToolTip(tip)
action.setStatusTip(tip)
if slot is not None:
self.connect(action, SIGNAL(signal), slot)
if checkable:
action.setCheckable(True)
return action
def main():
app = QApplication(sys.argv)
form = AppForm()
form.show()
app.exec_()
if __name__ == "__main__":
main()
I should mention that the latest test was on a windows 32 bit xp box. On Mon, Aug 31, 2009 at 11:51 AM, william ratcliff < wil...@gm...> wrote: > Ok, I upgraded to python 2.6, installed mpl 0.99 qt 4.5, and the new pyqt > and things are more responsive...However, the difference between having that > line in and taking it out are the difference between having pan/zoom events > being extremely responsive and having an extremely noticeable lag. I've > attached a test file from the web which is rather simple. You can notice > the lag if you either try to pan/zoom using the toolbar, or if you try to > use the slider to change the sizes of the horizontal bars. > > Sigh, upgrading everything to 2.6 is going to be a chore... > > > Thanks, > William > > > On Mon, Aug 31, 2009 at 11:30 AM, Darren Dale <dsd...@gm...> wrote: > >> I've been using 2.6. It should be fine on windows now, but I can't >> attest to it since I only use windows when I have to test and make >> windows installers. >> >> On Mon, Aug 31, 2009 at 10:02 AM, william >> ratcliff<wil...@gm...> wrote: >> > Let me try to upgrade to PyQt 4.5--I'm currently using 4.4.3 on vista 32 >> > bit. Btw. are you using python 2.6 or 2.5 (I ask because I'm still on >> 2.5 >> > and am wondering if anyone has noticed any difficulties with 2.6). >> > >> > Cheers, >> > Wiliam >> > >> > On Mon, Aug 31, 2009 at 9:36 AM, Darren Dale <dsd...@gm...> >> wrote: >> >> >> >> Hi William, >> >> >> >> On Mon, Aug 31, 2009 at 8:25 AM, william >> >> ratcliff<wil...@gm...> wrote: >> >> > Hi! I just installed matplotlib version .99 (windows vista, >> python25, >> >> > 32bit) and found that >> >> > this line was missing: >> >> > QtGui.qApp.processEvents() >> >> > >> >> > Adding it sped the QT4Agg backend back to reasonable speeds--but it >> >> > still >> >> > seems a bit slow. Otherwise, I am using the excellent Python(x,y) >> >> > 2.1.14 >> >> > release for my python distribution on this machine. Could this line >> be >> >> > added back? >> >> >> >> Unfortunately, no, that line can not be added back in. When that line >> >> is in place, the backend attempts to process queued events before it >> >> is finished processing the current event. It was leading to segfaults >> >> in some cases. processEvents should not be called in the middle of >> >> processing an event. >> >> >> >> I tested the responsiveness of panning and zooming with and without >> >> that call to processEvents, on Linux and windows and it looked fine. >> >> Maybe its an issue related to a specific Qt version on windows. Things >> >> looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista. >> >> >> >> Darren >> > >> > >> >> >> >> -- >> "In our description of nature, the purpose is not to disclose the real >> essence of the phenomena but only to track down, so far as it is >> possible, relations between the manifold aspects of our experience" - >> Niels Bohr >> >> "It is a bad habit of physicists to take their most successful >> abstractions to be real properties of our world." - N. David Mermin >> >> "Once we have granted that any physical theory is essentially only a >> model for the world of experience, we must renounce all hope of >> finding anything like the correct theory ... simply because the >> totality of experience is never accessible to us." - Hugh Everett III >> > >