Bugs in Qt4 backend with the latest PyQt release

Development matplotlib-devel
1

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

test_mpl_qt4.py (1.76 KB)

2

Hi Pierre,

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

···

On Saturday 16 August 2008 03:08:49 am Pierre Raybaut wrote:

3

Hi Darren,

2008/8/18 Darren Dale <dsdale24@...149...>:

(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

4

Hi Darren,

2008/8/18 Darren Dale <dsdale24@...149...>:
>> (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

···

On Monday 18 August 2008 09:33:47 am Pierre Raybaut wrote:

5

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

6

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

···

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?

7

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 Pierre Raybaut wrote:

Hi Darren,

2008/8/18 Darren Dale <dsdale24@...149...>:
>> (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.

8

Hi Darren,

2008/8/18 Darren Dale <dsdale24@...149...>:

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

9

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

10

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

11

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:mdroe@…31…]
Sent: Thursday, September 11, 2008 5:50 AM
To: Ted Drain
Cc: matplotlib-devel@lists.sourceforge.net
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

12

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 <contact@…604…> wrote:

Hi Darren,

2008/8/18 Darren Dale <dsdale24@…272…149…>:

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

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

13

Hi William,

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

···

On Mon, Aug 31, 2009 at 8:25 AM, william ratcliff<william.ratcliff@...149...> wrote:

14

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 <dsdale24@…149…> wrote:

Hi William,

On Mon, Aug 31, 2009 at 8:25 AM, william > > ratcliff<william.ratcliff@…149…> 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

15

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<william.ratcliff@...149...> 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 <dsdale24@...149...> wrote:

Hi William,

On Mon, Aug 31, 2009 at 8:25 AM, william >> ratcliff<william.ratcliff@...149...> 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

16

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

qt_mpl_bars.py (7.03 KB)

···

On Mon, Aug 31, 2009 at 11:30 AM, Darren Dale <dsdale24@…149…> 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<william.ratcliff@…149…> 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 <dsdale24@…149…> wrote:

Hi William,

On Mon, Aug 31, 2009 at 8:25 AM, william > > >> ratcliff<william.ratcliff@…149…> 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

17

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 <william.ratcliff@…149…> 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 <dsdale24@…149…> 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<william.ratcliff@…149…> 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 <dsdale24@…149…> wrote:

Hi William,

On Mon, Aug 31, 2009 at 8:25 AM, william > > > > >> ratcliff<william.ratcliff@…149…> 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

18

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<william.ratcliff@...149...> 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 <dsdale24@...149...> 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<william.ratcliff@...149...> 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 <dsdale24@...149...> wrote:
>>
>> Hi William,
>>
>> On Mon, Aug 31, 2009 at 8:25 AM, william >> >> ratcliff<william.ratcliff@...149...> 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

19

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 <dsdale24@…149…> 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<william.ratcliff@…149…> 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 <dsdale24@…149…> 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<william.ratcliff@…149…> 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 <dsdale24@…149…> wrote:

Hi William,

On Mon, Aug 31, 2009 at 8:25 AM, william > > >> >> ratcliff<william.ratcliff@…149…> 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