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).

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 :/

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?

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.

On 2015/07/23 7:16 AM, Peter Würtz wrote:

also the complexity of the matplotlib event handlers increased as the
development proceeded to the point where the handler time surpasses the
event rate.

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.

@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:

Ultimately the problem is that the wheelEvents come in too fast for QWebView to keep up. By accumulating the wheelEvents and delivering them in one packet every 25 ms, QWebView has enough time in between to handle them.

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.

This also happen in the nbagg backend and seems to be caused by #3989 as removing the hitlist checking makes it snappy again.

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.

@jrevans Thanks for putting in the work to track this down.

See the discussion in #4813 as well.

@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.

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__)

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.

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.

"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 [email protected] wrote:

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 https://github.com/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.

—
Reply to this email directly or view it on GitHub
#4767 (comment)
.

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 [email protected] wrote:

"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 [email protected]
wrote:

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 https://github.com/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.

—
Reply to this email directly or view it on GitHub
<
#4767 (comment)

.

—
Reply to this email directly or view it on GitHub
#4767 (comment)
.

Updating the status bar text in Qt5 seems to be another slow path. Please check if PR #4894 changes anything for you.

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.

@pwuertz How are things on the master branch for you now?

On current master, the qt5 backend is pretty responsive now (even with the event compression problem mentioned in the qt bug report).

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).