This PR actually only has a single failure (the same in all python versions):

======================================================================
FAIL: matplotlib.tests.test_offsetbox.test_offsetbox_clip_children
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/build/matplotlib/matplotlib/venv/lib/python2.6/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/home/travis/build/matplotlib/matplotlib/venv/lib/python2.6/site-packages/matplotlib-1.5.dev1-py2.6-linux-x86_64.egg/matplotlib/testing/decorators.py", line 110, in wrapped_function
    func(*args, **kwargs)
  File "/home/travis/build/matplotlib/matplotlib/venv/lib/python2.6/site-packages/matplotlib-1.5.dev1-py2.6-linux-x86_64.egg/matplotlib/tests/test_offsetbox.py", line 83, in test_offsetbox_clip_children
    assert_true(fig.stale)
AssertionError

Turns out the issue was that funny things were happening with the offsetbox subclasses which was getting masked by the fact that before artists were pinging both the axes and the figure, now they just hit the figure.

There are probably a bunch more issues like this that we will slowly find...

@rmorshea the stale callbacks have been simplified to not use pchanged anymore. I think this will make replicating the current proposed behavior easier.

I definitely see this as an improvement, modulo investigating the Travis failure. Possibly more to do over time, but I don't see any reason not to do this much now.

The travis issue is triggering draws in a draw. This is caused by:

• not checking if anything actually changed, just setting stale on every setter so stale gets triggered during draws
• the stale state now propagating past existing stale = True states
• Agg not having an asynchronous draw method and draw_idle just passing through to draw.

@mdehoon makes the very good point that due to our late validation of values if you set an invalid value you don't find out until draw time. If the stale state does not propagate past the existing stale artists and you are using plain python then a re-draw won't be triggered the next time the value is changed (as implemented with IPython it will work fine as-is).

The solutions to this that I see are:

• put back in the short circuit logic back in and tell people not to use plain python (I am +0 on this, and @mdehoon is -1)
• do proper validation and change determination in ever setter (I am -1 on this as traitlets will take care of this)
• make Agg's draw_idle re-entrant (I am +0 and am guessing @mdehoon is +1)

I am working on adding a commit to make the base draw_idle re-entrant.

I think this is ready to go again.

Still, I don't see the value in using sets here, and I don't like that it works now on a technicality. A list would work just fine. It isn't like we are expecting to have many figures to check against. At the extreme end, i would imagine someone doing something fancy with 10 figures, but typically, only 1 or 3 figures.

I disagree about it working on a "technicality"--this is documented python behavior, essentially making the in check work using is. In fact, using in (which uses __eq__) ends up on the same code path as hash:

User-defined classes have __eq__() and __hash__() methods by default; with them,
all objects compare unequal (except with themselves) and x.__hash__() returns an
appropriate value such that x == y implies both that x is y and hash(x) == hash(y).

(https://docs.python.org/3/reference/datamodel.html#object.__eq__)

However, I do agree that there is essentially no performance difference in our real-world scenarios here.

Ok, just tried out this branch. I was doing an imshow of a very large array (3600x7000), and a basemap plot and using the TkAgg backend. Watching "top" in another terminal, I see the memory usage increasing every time my mouse passes over the figure window. It never goes back down. The amount of memory increases by hundreds of MB for a quick pass over the window.

I don't know yet if it is because of this PR, or if it is due to some unfixed issue with stale flags, or something else entirely. Just noting it here for the moment.

Joys... this is on master and this branch. Furthermore, once you pass over the figure window, the memory usage keeps creeping up, even though the mouse is no longer over the window.

Try commenting out the mouse hover logic in backed base.

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

Joys... this is on master and this branch. Furthermore, once you pass over
the figure window, the memory usage keeps creeping up, even though the
mouse is no longer over the window.

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

Yup, looks like commenting out the contents of NavigationToolbar2.mouse_move "fixed" the problem. Do you think it is a bug to be dealt with here or shall I file a new issue?

Tack it on to the pr where i am working on removing hit list

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

Yup, looks like commenting out the contents of
NavigationToolbar2.mouse_move "fixed" the problem. Do you think it is a
bug to be dealt with here or shall I file a new issue?

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

I can still reproduce the original issue in #4732 when interactivity is on i.e. plt.ion()
However I can also reproduce the issue on 1.4.3 so I not really cure what to make of this

I.e if I call set_dashes('--') it triggers that exception on every draw until call set_dashes((1,1)) or whatever but surely that is just missing input validation?

That is the expected behavior, the problem was that previously correcting
the value would not trigger a redraw at all and the was no obvious way to
do so.

On Fri, Aug 14, 2015, 4:25 PM Jens Hedegaard Nielsen <
notifications@github.com> wrote:

I.e if I call set_dashes('--') it triggers that exception on every draw
until call set_dashes((1,1)) or whatever but surely that is just missing
input validation?

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

@tacaswell That makes sense. However, I can't reproduce that on current master.

set_dashes((3,'3)) after set_dashes(('--')) correctly triggers the redraw so it seems that either this has already been fixed by something else or I am doing something stupid. In any case this is an improvement to the stale login so I will go ahead and merge it

Are you using ipython or plain python? The redraw logic is different in the
two cases.

On Fri, Aug 14, 2015, 4:46 PM Jens Hedegaard Nielsen <
notifications@github.com> wrote:

Merged #4738 #4738.

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

plain python