| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Looking up MachAr was taking about 10ms which is way to slow to be inside of the mouse motion event loop. We are using it to get a constant so we can look it up and compute the constant once at the top.
|
@joferkington Do you work around this sort of thing in mpldatacursor? |
Sorry, something went wrong.
|
@tacaswell, I profiled a plot with 10000 random segments, and the contains method was taking <0.5ms. |
Sorry, something went wrong.
|
Granted, it was a single Line2D object... |
Sorry, something went wrong.
|
Otherwise, I agree that an artist should be able to opt out of mouse-move hit testing. |
Sorry, something went wrong.
|
This is a significant when testing on a plot with 100 lines. We might need to do more however I don't see any reason to hold this back |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This address some of #4767.
The issue in 604299f is that np.MachAr(float).xmin takes ~8-10 ms and gets 2x in the hitlist code path. Moving this to a constant at the top is a major speed up and for a blank figure gets the hitlist run time down to 5-6ms from a bit over 20ms (on the computer I was testing on).
There is still an issue that sorting out if the cursor hits a Line2D artist takes at least 1ms so if you have 300 lines, it takes a third of a second for the callback to run.
Long term, we should look into making this code faster by making contains run faster (a lot of time is spent in https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/lines.py#L36), by finding a way to cache this in a smart way but in the short term I think we need to add a per-axes way of turning this off and probably default to off.
attn @blink1073 @mdboom @pwuertz