Repository navigation
Regression Qt5 Backend #4767
Description
Qt5 GUI on Ubuntu is broken in master again. Moving the mouse pointer leads to a situation where the coordinate labels start lagging behind the movement. Git bisect pointed to commit 604299f.
I have not looked into the details yet, but it looks like there is a calculation happening that might take a little bit more CPU time after the patch. This alone shouldn't be an issue, but apparently this code path is again executed synchronously by the GUI event handler at high frequency, which should not be happening. The patch isn't responsible for this, the previous calculation probably just didn't cause the event loop to clog up.
Activity
tacaswell commented on Jul 23, 2015
Do we need to throttle the mouse move events?
#4769 takes a stab at this, but it does not make the zoom box responsive for me so I am not sure it is addressing the right problem (or we have some really slow code in the loop).
pwuertz commented on Jul 23, 2015
Yes, the zoom box seems to have the same issue. The zoom box is painted by the synchronous draw call only, which shouldn't have been called by the mouse move event either. So there are definitely some "bad" code paths leading to forced redraws and maybe additional code paths that are too slow for mouse event handlers. Maybe its best to identify those first instead of adding a throttling workaround. I'm afraid I can't help out as much as I'd like the next few days :/
tacaswell commented on Jul 23, 2015
Nor can I, I head off to pydata Seattle in < an hour.
Is my understanding that something in the mouse move events changed on the qt side between 4 and 5?
@mfitzp Are you around again?
pwuertz commented on Jul 23, 2015
I think the problematic event-to-redraw code paths have been around the whole time and/or are still hidden in the backend. They just haven't been noticed by everyone because the rate of emitted events differs for each system/version/platform and also the complexity of the matplotlib event handlers increased as the development proceeded to the point where the handler time surpasses the event rate. I could probably have a look in a week or so.
efiring commented on Jul 23, 2015
On 2015/07/23 7:16 AM, Peter Würtz wrote:
If so, perhaps we need a concerted effort to streamline our event
handlers. More generally, I'm concerned that we haven't been monitoring
performance of anything, while the code gets ever more complex.
mfitzp commented on Jul 23, 2015
@tacaswell Yep. I am back.
Is this related to the other bug and panning? As I mentioned in that one I suspect the problem is with Qt5 emitting a lot more mouse events. I remember coming across a similar or related issue with the QWebView widget that required a similar throttling (until something was patched elsewhere in Qt).
Rather than discarding the events the solution was to accumulate the events (the cumulative movement) and then emit after a given number of events, or after a specified time, whichever was first.
I'll dig out the old code and continue the discussion on that over on the fork.
This is the relevant Qt bug that was relating to behaviour of Qt4 on Mac. While a different platform + version (!) this resulted in a change in Qt5 to make it produce and handle much more fine grained events. It's these extra events that I suspect are causing these issues. Relevant bit:
We can either ensure matplotlib can handle the rate of events, or catch and throttle them to the rate matplotlib can handle. Some example throttling code from the above issue posted here.
tacaswell commented on Jul 26, 2015
This also happen in the nbagg backend and seems to be caused by #3989 as removing the hitlist checking makes it snappy again.
jrevans commented on Jul 29, 2015
After extensive debugging and profiling the problem was introduced with #3989 . This causes an immense overhead in the amount of time it takes for a single mouse move call. The number of calls does not need to be throttled (let the GUI do its thing). The problem lies with the 'hitlist' call adding 100% -> 1000% more time to the processing of a single mouse move (the more artists, the longer it takes). This slowdown is present for all backends. Right now dealing with any semi-complicated plot and the GUI becomes unusable.
tacaswell commented on Jul 29, 2015
@jrevans Thanks for putting in the work to track this down.
See the discussion in #4813 as well.
tacaswell commented on Jul 31, 2015
@pwuertz @jrevans Can you check how master behaves for you now?
I now am seeing that zoom and the mouse move work ok, but pan is laggy.
tacaswell commented on Jul 31, 2015
import numpy as np import matplotlib.pyplot as plt for j in range(100): plt.plot(np.random.rand(1500))Is the test case I am using.
Qt4 is laggy, but not as bad.
In any case, the problem with that test case is that it is some what pathological as our path simplification code can't do much and it take ~2s to render (via %prun) on my computer on python 3. This is comparable to performance with 1.4.3 and 1.3.1.
In all cases, the lions share of the time is in
ncalls tottime percall cumtime percall filename:lineno(function) 106 1.943 0.018 1.943 0.018 {built-in method draw_path} 130 0.006 0.000 1.983 0.015 lines.py:661(draw) 294 0.003 0.000 0.006 0.000 path.py:199(_update_values) 400 0.002 0.000 0.002 0.000 {method 'reduce' of 'numpy.ufunc' objects} 386 0.002 0.000 0.003 0.000 colors.py:334(to_rgba) 581 0.002 0.000 0.002 0.000 weakref.py:101(__init__) 106 0.002 0.000 1.945 0.018 backend_agg.py:140(draw_path) 294 0.001 0.000 0.008 0.000 path.py:103(__init__) 200 0.001 0.000 0.001 0.000 {method 'searchsorted' of 'numpy.ndarray' objects} 100 0.001 0.000 0.002 0.000 _base.py:2485(get_xlim) 130 0.001 0.000 0.010 0.000 lines.py:623(_transform_path) 250/140 0.001 0.000 0.004 0.000 transforms.py:2314(get_affine) 492 0.001 0.000 0.001 0.000 {built-in method array} 984 0.001 0.000 0.001 0.000 __init__.py:871(__getitem__)pwuertz commented on Aug 3, 2015
I tested the current master with your latest changes. For me it restored basic GUI interaction for very simple figures. The rubberband selection though still hits a slow path and the GUI breaks down pretty early when trying to draw a line with a "few" more points (~ few thousand).
I didn't have the time for a more thorough look at the backend yet. For a current project I urgently needed a fast GUI for plotting a medium amount of data, which unfortunately ended up in building my own qt optimized plotting solution. I wonder how to proceed with the matplotlib GUI backend(s). The interface isn't really suited for handling large amounts of data interactively (since matplotlibs focus lies on publication quality output, not user interfaces), so we probably need to define some upper limit use case that we want to work smoothly in any case. Right now I can't tell if freezing the GUI at few thousand line segments is expected or considered a problem.
TD22057 commented on Aug 5, 2015
FYI - we're seeing massive (i.e. unusable) slow downs when upgrading from 1.4 to 1.5 (and qt4->qt5). I don't know if it's the event handling code that @efiring alluded to or not but we see big slow downs in artist construction, artist drawing, and artist re-drawing. As soon as we have time (hopefully next week) we'll get standalone test cases and open a separate bug report for each of them but something has caused almost everything to get a lot slower even when drawing is not involved.
WeatherGod commented on Aug 5, 2015
"while upgrading from 1.4 to 1.5"
Just to be clear, we haven't released 1.5 yet, and we have some PRs that
addresses some of the known slowdowns. When we put out the release
candidate, then these performance tests would be crucial to make sure we
caught everything.
On Wed, Aug 5, 2015 at 1:01 PM, Ted Drain notifications@github.com wrote:
tacaswell commented on Aug 5, 2015
Exactly what commit are you on? I think this regression is a blocker for
1.5
On Wed, Aug 5, 2015, 1:07 PM Benjamin Root notifications@github.com wrote:
pwuertz commented on Aug 10, 2015
Updating the status bar text in Qt5 seems to be another slow path. Please check if PR #4894 changes anything for you.
jrevans commented on Aug 10, 2015
I have stumbled across this Qt bug report: https://bugreports.qt.io/browse/QTBUG-40889 After applying the posted patch, things do get quite a bit better. There is still a significant percentage slowdown from the original matplotlib code to the current code, but the Qt responsiveness is greatly improved.
tacaswell commented on Aug 17, 2015
@pwuertz How are things on the master branch for you now?
pwuertz commented on Aug 19, 2015
On current master, the qt5 backend is pretty responsive now (even with the event compression problem mentioned in the qt bug report).
tacaswell commented on Aug 22, 2015
Closing this as it seems to be fixed and the qt related code has been thrashed enough this thread has comments addressing many different code states.
If this issue comes back please re-open (and include the githash you are working off of).