What would be wrong with checking a.mouseover directly and avoiding mouseover_set?

I was trying to avoid walking the artist tree at all and avoid changing hit
list which i assume is used else where.

On the other hand, self.get_children would only do one layer, be only a bit
slower (I am guessing which I know is always a bad idea) and be a lot
simpler.

On Fri, Aug 7, 2015, 9:05 AM Steven Silvester notifications@github.com
wrote:

What would be wrong with checking a.mouseover directly and avoiding
mouseover_set?

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

You're right, it makes more sense the way it is now.

I prefer this approach to using the hitlist, it's cleaner and easier to follow what's being reported.

@tacaswell I think this would be a good place to also address #4284 making, a similar property in axes, to report or not.

@fariza Possibly, but by the time we get to this code, the decision about what Axes to hand the event to to process has already been made, although it is probably simple to look up if there are any twin axes here.

I am inclined to punt on that to get the mouse-over code shippable ASAP.

Initially reported over in #4738 , I encountered a very troubling bug with NavigationToolbar2.mouse_over. When I display a very large image (haven't tried smaller images), and I pass the mouse over the figure window, memory usage increases by 100s of MBs every few seconds, and it doesn't seem to stop increasing. I eventually have to kill -9 the process when it gets up to around 5GB. This behavior is present even with this PR.

Also close #4918

@matplotlib/developers I think this is ready to go.

Forgot this last thing from been when i was working on this/writing up the
current state last night.

On Wed, Aug 12, 2015, 2:54 PM Benjamin Root notifications@github.com
wrote:

Initially reported over in #4738
#4738 , I encountered a
very troubling bug with NavigationToolbar2.mouse_over. When I display a
very large image (haven't tried smaller images), and I pass the mouse over
the figure window, memory usage increases by 100s of MBs every few seconds,
and it doesn't seem to stop increasing. I eventually have to kill -9 the
process when it gets up to around 5GB. This behavior is present even with
this PR.

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

Been should be Ben.

On Fri, Aug 14, 2015, 8:08 AM Thomas Caswell tcaswell@gmail.com wrote:

Forgot this last thing from been when i was working on this/writing up the
current state last night.

On Wed, Aug 12, 2015, 2:54 PM Benjamin Root notifications@github.com
wrote:

Initially reported over in #4738
#4738 , I encountered a
very troubling bug with NavigationToolbar2.mouse_over. When I display a
very large image (haven't tried smaller images), and I pass the mouse over
the figure window, memory usage increases by 100s of MBs every few seconds,
and it doesn't seem to stop increasing. I eventually have to kill -9 the
process when it gets up to around 5GB. This behavior is present even with
this PR.

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

I did a little bit more investigation on this. The data I was displaying
were masked arrays from netCDF4 objects. Meanwhile, if I simply create
large masked arrays with random data, I cannot reproduce the problem. So,
perhaps there is something about how we are interacting with views of data
that (I believe) is memmapped?

On Fri, Aug 14, 2015 at 8:09 AM, Thomas A Caswell notifications@github.com
wrote:

Been should be Ben.

On Fri, Aug 14, 2015, 8:08 AM Thomas Caswell tcaswell@gmail.com wrote:

Forgot this last thing from been when i was working on this/writing up
the
current state last night.

On Wed, Aug 12, 2015, 2:54 PM Benjamin Root notifications@github.com
wrote:

Initially reported over in #4738
#4738 , I encountered a
very troubling bug with NavigationToolbar2.mouse_over. When I display a
very large image (haven't tried smaller images), and I pass the mouse
over
the figure window, memory usage increases by 100s of MBs every few
seconds,
and it doesn't seem to stop increasing. I eventually have to kill -9 the
process when it gets up to around 5GB. This behavior is present even
with
this PR.

—
Reply to this email directly or view it on GitHub
<
https://github.com/matplotlib/matplotlib/pull/4878#issuecomment-130411057>
.

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

The test error on python 2.6 looks real

ERROR: Failure: AttributeError ('module' object has no attribute 'test_artist')
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/build/matplotlib/matplotlib/venv/lib/python2.6/site-packages/nose/loader.py", line 407, in loadTestsFromName
    module = resolve_name(addr.module)
  File "/home/travis/build/matplotlib/matplotlib/venv/lib/python2.6/site-packages/nose/util.py", line 322, in resolve_name
    obj = getattr(obj, part)
AttributeError: 'module' object has no attribute 'test_artist'

The failure is due to import errors in test_artist in 2.6, hurray.

I really want to just drop 2.6, but I will get this sorted out.

Im 👍 on dropping python 2.6 but I guess should keep it round for 1.5 and 2.0. Skipping the tests on Python 2.6 is IMHO an acceptable solution if the import error is in the test.

Drop 2.6??? Could we do that for 2.x? OrderedDicts here we come! 😄.

The problem was that some of the fancier assert statements are not in 2.6, but are every where else (despite nose having the same version). I just switched to using assert_true which is easier than setting up conditional tests and local imports.

@pelson I agree this isn't great, but the hitlist solution was taking longer to run than the time between mouse events and the automatic mouse-over functionality is one people have been asking for for years.

Another option I see is to periodically walk the children and cache which of them have a message to add to the mouse over string, but that has a higher chance of going out of sync than this method does.

I have no problem renaming mouseover_set.