Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
MNT: overhaul stale handling#4738
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
MNT: overhaul stale handling#4738
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Only propagate stale state to the figure from it's direct children,not all artists. This is to prevent double call backs when usinginteractive mode with backends which do not implement an asynchronousdraw_idle.
This is to match the behavior of artists being uniquely associated witha single Axes.
If a draw has been forced, but either the figure or axes is not stalesome of the draw processes will cause them to become scale (becausethe current implementation is naive and does no check if values havechanged so no-op sets still mark the artist as stale). By setting_stale to be True the stale events will not propagate past theaxes/figure and schedule another redraw.This only really matters for Canvas classes which do not implement anasynchronous `draw_idle`. If there is an asynchronous `draw_idle` theadditional draw requests will be ignored until the current drawis finished anyway.
This PR actually only has a single failure (the same in all python versions): |
When setting the axes of an offset box to propagate to it's children.
Turns out the issue was that funny things were happening with the There are probably a bunch more issues like this that we will slowly find... |
d168e59 tob39fd90CompareDo not re-use a much too broad callback registry for propagatingstale state.
@rmorshea the stale callbacks have been simplified to not use |
Always propagate stale up (even if immediate parent is stale)
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
@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:
I am working on adding a commit to make the base |
Calling `draw_idle` while executing a `draw_idle` will no-longerinfinitely recurse.
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 (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 Rootnotifications@github.com
|
Yup, looks like commenting out the contents of |
Tack it on to the pr where i am working on removing hit list On Wed, Aug 12, 2015, 2:41 PM Benjamin Rootnotifications@github.com
|
- disconnect the stale_callback (this assumes thatmatplotlib#4738 goes in) - remove the artist from the Axes.mousover_set - marks the parent axes/figure as stale - resets the artist's axes/figure to None
Artists do not properly guard against being removed from figures or Axeswhen tracking 'stale'. This will keep them from throwing an exception ifthey become stale after being removed from an Axes or Figure.
Look at figures, not axes, and use a set
- short circuit if not really chaning state - don't fire stale trigger on changing animation state
When using blitting in animation make sure to set the blitted artsts asanimated so that changing their state does not trigger the normal stale-> draw_idle cascade.
ce80568 to25079bfCompareI can still reproduce the original issue in#4732 when interactivity is on i.e. |
I.e if I call |
That is the expected behavior, the problem was that previously correcting On Fri, Aug 14, 2015, 4:25 PM Jens Hedegaard Nielsen <
|
@tacaswell That makes sense. However, I can't reproduce that on current master.
|
MNT: overhaul stale handling
Are you using ipython or plain python? The redraw logic is different in the On Fri, Aug 14, 2015, 4:46 PM Jens Hedegaard Nielsen <
|
plain python |
Closes#4732