Hi Ole,<br><br><div class="gmail_quote">On Tue, Jul 7, 2009 at 11:33 AM, Ole Streicher <span dir="ltr"><<a href="mailto:ole-usenet-spam@gmx.net">ole-usenet-spam@gmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi again,<br>
<div class="im"><br>
Darren Dale <<a href="mailto:dsdale24@gmail.com">dsdale24@gmail.com</a>> writes:<br>
</div><div class="im">> Nice demonstration of the problem Ole. I notice that if, after<br>
> resizing, I pause briefly before releasing the mouse button, the<br>
> scroll bar is more likely to resize properly. The problem is much more<br>
> apparent if I release the mouse button immediately after resizing or<br>
> while still dragging the window edge.<br>
<br>
</div>I already created a Qt bug report for that (issue number #255433, not public<br>
for some reason). They asked me to compile a C++ only variant of the<br>
bug.<br>
<br>
However, I could not reproduce the problem in C++: the events occure here<br>
always in-order independent of the processing times in the (simulated)<br>
inner widget resize time.<br>
<br>
I could also not reproduce the bug in PyQt4 without matplotlib by<br>
replacing the FigureCanvasQTAgg with a QFrame and adding some random<br>
sleep to the resize function.<br>
<br>
But, with some stacktracing, I found the reason:<br>
<br>
in matplotlib.FigureCanvasQTAgg, the following piece of code is called<br>
on a resizeEvent:<br>
<br>
def draw( self ):<br>
<br>
# ... some internal code<br>
<br>
# Added following line to improve realtime pan/zoom on windows:<br>
QtGui.qApp.processEvents()<br>
<br>
This makes the problem clear:<br>
- if we resize the window quickly, several resizeEvents are created and<br>
are in the event queue of Qt<br>
- the first one gets processed by the QVBoxLayout which starts the<br>
processing in its first (matplotlib) widget.<br>
- the matplotlib widget does what it should and at some point calls<br>
matplotlib.FigureCanvasQTAgg.draw(self).<br>
- this starts the processing of the next event in the queue which is<br>
the next (2nd) resize event. BUT: we are still in the processing of<br>
the first event!!!<br>
- the 2nd event goes to the QVBoxLayout, from there to the matlotlib<br>
widget (eventually starting some recursive behaviour here)<br>
- if the 2nd event is finished, QVBoxLayout sends it to its other widget<br>
(the scrollbar). The scrollbar is resized according to the *2nd event*.<br>
- if the processing of the 2nd event was finished and no more events are<br>
in the queue, the matplotlib.FigureCanvasQTAgg.draw() finishes<br>
- at the end, this will finish the processing of the first resize event<br>
in the matplotlib widget and start the *first resize event* for the<br>
scrollbar<br>
<br>
This is exactly the behaviour that I described in my first posting. It<br>
is caused by the QtGui.qApp.processEvents() call in the draw() function.<br>
<br>
So, I think this is clearly a bug in matplotlib:<br>
QtGui.qApp.processEvents() should not be called while processing another<br>
event.<br>
<br>
Darren, I dont know your position with respect to matplotlib: are you a<br>
developer and thus aware of the bug or shall I post this again on the<br>
matplotlib mailing list?<br>
</blockquote><div><br>I am a developer, but I think it would be good to post your summary there at the matplotlib mailing list so we can continue this discussion there.<br><br>Darren<br></div></div>