Eric,
I installed mpl from git ("git clone git://github.com/matplotlib/matplotlib.git", unless I was suppose to use one of the branches) and same problem. I looked at my code again and thought there should be a canvas.draw() before calling "c.copy_from_bbox(a.bbox)", but still the same problem. However, I did have it work the first time I added "c.draw()" and used the git mpl, and by work I mean that everything stayed visible on the figure.
When people start coming in to my work I'll ask them to run my sample code and see what happens. It almost seems like mpl is handling the window activation event funny, is there an easy way to print out the callbacks being used by a mpl figure? For now, I will subclass QApplication, and implement "notify()" to print out events as they come in, but still...this is just weird. Thanks.
-Dave
···
On 12/14/11 10:30 PM, Eric Firing wrote:
David,
It works for me on linux with mpl from git. I haven't tried to figure
it out, but it is conceivable that the problem you are seeing was fixed
with this:
commit b624546ae60dc5878e75a32f41a160d383548b8f
Author: Eric Firing<efiring@...202...>
Date: Tue Oct 18 08:06:21 2011 -1000
backend_qt4agg: draw() immediately calls FigureCanvasAgg.draw()
This is the latest in a series of modifications to the Qt4Agg
drawing strategy going back several years. It simplifies the
code and should solve the problem introduced in 6938b0025; that
is, delaying the Agg draw operation until the paintEvent breaks
code expecting that draw operation to have occurred immediately.
The problem was reported here:
[Matplotlib-users] QT draw issue in 1.1.0 and PyQt4v2 missing? | matplotlib
Eric
Oops forgot to change subject.
···
On 12/15/11 10:02 AM, David Hoese wrote:
Eric,
I installed mpl from git ("git clone git://github.com/matplotlib/matplotlib.git", unless I was suppose to use one of the branches) and same problem. I looked at my code again and thought there should be a canvas.draw() before calling "c.copy_from_bbox(a.bbox)", but still the same problem. However, I did have it work the first time I added "c.draw()" and used the git mpl, and by work I mean that everything stayed visible on the figure.
When people start coming in to my work I'll ask them to run my sample code and see what happens. It almost seems like mpl is handling the window activation event funny, is there an easy way to print out the callbacks being used by a mpl figure? For now, I will subclass QApplication, and implement "notify()" to print out events as they come in, but still...this is just weird. Thanks.
-Dave
On 12/14/11 10:30 PM, Eric Firing wrote:
David,
It works for me on linux with mpl from git. I haven't tried to figure
it out, but it is conceivable that the problem you are seeing was fixed
with this:
commit b624546ae60dc5878e75a32f41a160d383548b8f
Author: Eric Firing<efiring@...202...>
Date: Tue Oct 18 08:06:21 2011 -1000
backend_qt4agg: draw() immediately calls FigureCanvasAgg.draw()
This is the latest in a series of modifications to the Qt4Agg
drawing strategy going back several years. It simplifies the
code and should solve the problem introduced in 6938b0025; that
is, delaying the Agg draw operation until the paintEvent breaks
code expecting that draw operation to have occurred immediately.
The problem was reported here:
[Matplotlib-users] QT draw issue in 1.1.0 and PyQt4v2 missing? | matplotlib
Eric
Eric,
Good news I think I got it to work. So using the same code I sent you originally, I applied the following changes:
1. Install matplotlib from git (this did fix things that I wasn't noticing)
2. Add c.draw() before "c.copy_from_bbox"
3. Copy "f.bbox" instead of "a.bbox" (I think this makes sense since I want it to hold on to the title,ticks, and labels, a.bbox is only the content inside the axis rectangle)
4. Restore f_bbox, blit f.bbox.
...and it seems to work. The git version of mpl did fix this, although restoring just the a.bbox was only keeping the axis rectangle so it made it look like even worse of a bug. Using the new version I noticed this and then started using f.bbox which seems to work the way I want it.
Now, my final question is: Is this actually doing what I want performance-wise. When I blit just f.bbox, is it really only repainting the updated line or is it redrawing most of the figure? If you need a copy of the new version of my test code let me know. Thanks for any more clarity/help you can give.
-Dave
P.S. Is there a book or tutorial or website where I can learn more about how the rendering/painting of stuff like this works. For example, if I could better understand why your bug fix was needed.
···
On 12/15/11 10:04 AM, David Hoese wrote:
Oops forgot to change subject.
On 12/15/11 10:02 AM, David Hoese wrote:
Eric,
I installed mpl from git ("git clone git://github.com/matplotlib/matplotlib.git", unless I was suppose to use one of the branches) and same problem. I looked at my code again and thought there should be a canvas.draw() before calling "c.copy_from_bbox(a.bbox)", but still the same problem. However, I did have it work the first time I added "c.draw()" and used the git mpl, and by work I mean that everything stayed visible on the figure.
When people start coming in to my work I'll ask them to run my sample code and see what happens. It almost seems like mpl is handling the window activation event funny, is there an easy way to print out the callbacks being used by a mpl figure? For now, I will subclass QApplication, and implement "notify()" to print out events as they come in, but still...this is just weird. Thanks.
-Dave
On 12/14/11 10:30 PM, Eric Firing wrote:
David,
It works for me on linux with mpl from git. I haven't tried to figure
it out, but it is conceivable that the problem you are seeing was fixed
with this:
commit b624546ae60dc5878e75a32f41a160d383548b8f
Author: Eric Firing<efiring@...202...>
Date: Tue Oct 18 08:06:21 2011 -1000
backend_qt4agg: draw() immediately calls FigureCanvasAgg.draw()
This is the latest in a series of modifications to the Qt4Agg
drawing strategy going back several years. It simplifies the
code and should solve the problem introduced in 6938b0025; that
is, delaying the Agg draw operation until the paintEvent breaks
code expecting that draw operation to have occurred immediately.
The problem was reported here:
[Matplotlib-users] QT draw issue in 1.1.0 and PyQt4v2 missing? | matplotlib
Eric