👍

Failures are pickles not being sanitized enough on the way out (the local function is not pickleable). Should probably fix that, but the faster solution is to move the auto_redraw function to be a top level function (and thus be pickable).

I did a little quick testing, and it looks great! Is there any real disadvantage to making auto_redraw top-level?

Nope, just me solving this in the first way that popped into my head on the train. I was thinking this was going to be a closure, but it is not.

Not sure what is wrong with the build, it seems to build fine locally, but is stalling on travis.

sorry ^doc build

No that's puzzling. It looks like both jobs hung in or after the same example: examples/mplot3d/rotate_axes3d_demo

now, that's interesting. rotate_axes3d_demo.py is a bit of an oddball. It and wire3d_animation_demo.py are the only two doc build examples that calls plt.ion(). There is also widgets/lasso_selector_demo.py, but I think the doc-build skips that one.

Ah, should try to run it locally with the rcparams that are used on Travis.
Failing to see why draw idle would be a problem with agg tough.

On Tue, Jun 9, 2015, 10:57 Benjamin Root notifications@github.com wrote:

now, that's interesting. rotate_axes3d_demo.py is a bit of an oddball. It
and wire3d_animation_demo.py are the only two doc build examples that calls
plt.ion(). There is also widgets/lasso_selector_demo.py, but I think the
doc-build skips that one.

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

so, I am now very confused as no 3D things are working for me on master either:

Traceback (most recent call last):
  File "/home/tcaswell/source/my_source/matplotlib/lib/matplotlib/backends/backend_qt5.py", line 343, in resizeEvent
    self.draw()
  File "/home/tcaswell/source/my_source/matplotlib/lib/matplotlib/backends/backend_qt5agg.py", line 147, in draw
    FigureCanvasAgg.draw(self)
  File "/home/tcaswell/source/my_source/matplotlib/lib/matplotlib/backends/backend_agg.py", line 475, in draw
    self.figure.draw(self.renderer)
  File "/home/tcaswell/source/my_source/matplotlib/lib/matplotlib/artist.py", line 60, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/home/tcaswell/source/my_source/matplotlib/lib/matplotlib/figure.py", line 1122, in draw
    func(*args)
  File "/home/tcaswell/.virtualenvs/dd_3k/lib/python3.4/site-packages/mpl_toolkits/mplot3d/axes3d.py", line 273, in draw
    ax.draw(renderer)
  File "/home/tcaswell/.virtualenvs/dd_3k/lib/python3.4/site-packages/mpl_toolkits/mplot3d/axis3d.py", line 264, in draw
    self.axes.transAxes.transform(peparray[0:2, 0]))
ValueError: Expected 2-dimensional array, got 1

and I am now completely flumoxed. I have pulled out the values of peparray above:

This works

In [28]: ax.transAxes.transform(np.array(dd[0:2, 0]))
Out[28]: array([ 67.42554669,  57.0430007 ])

This fails:

In [32]: a = ax.transAxes.transform(np.array(dd[0:2, 0]))
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
ValueError: Expected 2-dimensional array, got 1

This works:

In [36]: a = ax.transAxes.transform([-0.07047539, -0.05412152])

This does not:

In [35]: a = ax.transAxes.transform(np.array([-0.07047539, -0.05412152]))
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
ValueError: Expected 2-dimensional array, got 1

and

In [38]: a = ax.transAxes.transform(list(dd[0:2, 0]))

In [39]: a = ax.transAxes.transform(dd[0:2, 0])
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
ValueError: Expected 2-dimensional array, got 1

In [40]: 

For those playing along at home:

In [37]: dd
Out[37]: 
array([[-0.07047539,  0.01976701],
       [-0.05412152, -0.08365497],
       [-0.99055809, -1.03688574]])

and

fig = plt.figure()
ax = fig.add_subplot(111, projection='3d')

Sorry, I hope no one wasted any time on this.

The root cause seems to be crossed installations on my end, sorry for the noise.

Removing the plt.ion() from those demos fixed the build. I should probably figure out what awful subtle thing is going wrong...

I still need to deal with @WeatherGod 's comment about the order of calling plt.ion and creating a figure and the comment I dismissed above about keeping track of the id's of the call backs to remove them when plt.ioff() is called (I was mostly being lazy, sorry Ben).

@mdehoon, @tacaswell, I have tested this with Python 2.7 (Homebrew) and macosx backend, using the python -i test.py method. It works, but there is a delay of about 5 seconds from the time the window is displayed until the plot is drawn and the terminal cursor returns. With qt4agg and tkagg there is little or no delay. (Tk actually seems snappier than qt4agg, but it's not a big difference.) @mdehoon, where do you think the 5-s delay is coming from? Is there an easy way to avoid it?

Side note: with interactive : True in matplotlibrc, standard mpl scripts ending with plt.show() don't work; because show doesn't block in interactive mode, running such a script from the command line in the normal way, without an explicit python -i, will just flash the plot on the screen. This suggests to me that having the interactive : True option in matplotlibrc is a bad design, so perhaps the matplotlibrc_template should include a comment warning against it. I suspect we've avoided bug reports about this only because few people use their own matplotlibrc file; probably most mpl users are blissfully unaware of it, fortunately.

@efiring OK I will have a look.

@efiring

where do you think the 5-s delay is coming from? Is there an easy way to avoid it?

This turned out to be a trivial problem. The MacOSX backend doesn't implement the draw_idle function, so matplotlib was calling draw_idle in the base class. However, the required functionality is available in the C extension, where it's called "invalidate" (this is what is currently used in draw_if_interactive). If I add a draw_idle method to FigureCanvasMac and let it call self.invalidate(), then everything seems to work fine.

Perhaps related to @OceanWolf 's question: What is the purpose of using the callback functions _stale_figure_callback and _stale_axes_callback instead of setting figure.stale and axes.stale directly in stale.setter?

@tacaswell, I had the same question as @mdehoon raised above; including a comment in the code to explain it might be helpful.
@mdehoon, if you have not already done so, would you submit a PR with the draw_idle method, please? Thanks.

It is a combination of the terrifying things that we do with the axes attribute and forward planning.

For 'normal' Artists it is the axes they are in, for Axes objects it if forbidden, and for Figure objects it is a list of the Axes it contains. If I recall correctly, I think I thought doing it with the callbacks was simpler than special-casing the stale property.

The other part is looking forward to what I want to do with containers, being able to do the dispatch to parent via the call back stack allows artists to notify their container (which will in turn notify the axes) that they are stale. Being able to keep track of which parts of the tree are stale might provide a path to auto-blitting in the Agg backends (as we know exactly which artists we need to re-render and which we can used cached versions of), but that is still vapor ware.

Side note: with interactive : True in matplotlibrc, standard mpl scripts ending with plt.show() don't work; because show doesn't block in interactive mode, running such a script from the command line in the normal way, without an explicit python -i, will just flash the plot on the screen.

Did I break that or has that always been the case?

@tacaswell, it's that way in master, and probably has always been that way, or at least has been in the modern era. It seems pretty fundamental.

@tacaswell, I'm inclined to merge this now; is there any reason I should wait?

I have been meaning to go back and re-work how the plain python shell
ion/ioff work. If you toggle them any existing figures will still
(not)have the callback on them so will persist with the previous behavior,
but all new figures will work properly.

It isn't hard, just some book keeping. If you want to merge this now I can
add that in as another PR.

On Thu, Jul 16, 2015 at 5:07 PM Eric Firing notifications@github.com
wrote:

@tacaswell https://github.com/tacaswell, I'm inclined to merge this
now; is there any reason I should wait?

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

Merged, so that we can get more people banging on it.

@efiring

if you have not already done so, would you submit a PR with the draw_idle method, please? Thanks.

Please see pull request #4731 .

This morning I updated matpotlib master and then installed trendvis I got an ValueError: Expected 2-dimensional array, got 1 error when trying one of the examples. Searching I found #3898 which led me here. Tried with one the mplot3d demos, lines3d_demo and got the same error:

$ python lines3d_demo.py 
/home/jscandal/sw/python/doct/ciarp07/lines3d_demo.py
Traceback (most recent call last):
  File "/home/jscandal/sw/matplotlib/matplotlib.py3/lib/matplotlib/backends/backend_qt5agg.py", line 74, in paintEvent
    FigureCanvasAgg.draw(self)
  File "/home/jscandal/sw/matplotlib/matplotlib.py3/lib/matplotlib/backends/backend_agg.py", line 471, in draw
    self.figure.draw(self.renderer)
  File "/home/jscandal/sw/matplotlib/matplotlib.py3/lib/matplotlib/artist.py", line 60, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/home/jscandal/sw/matplotlib/matplotlib.py3/lib/matplotlib/figure.py", line 1121, in draw
    func(*args)
  File "/usr/lib/python3.4/site-packages/mpl_toolkits/mplot3d/axes3d.py", line 273, in draw
    ax.draw(renderer)
  File "/usr/lib/python3.4/site-packages/mpl_toolkits/mplot3d/axis3d.py", line 264, in draw
    self.axes.transAxes.transform(peparray[0:2, 0]))
ValueError: Expected 2-dimensional array, got 1
Traceback (most recent call last):
  File "/home/jscandal/sw/matplotlib/matplotlib.py3/lib/matplotlib/backends/backend_qt5agg.py", line 74, in paintEvent
    FigureCanvasAgg.draw(self)
  File "/home/jscandal/sw/matplotlib/matplotlib.py3/lib/matplotlib/backends/backend_agg.py", line 471, in draw
    self.figure.draw(self.renderer)
  File "/home/jscandal/sw/matplotlib/matplotlib.py3/lib/matplotlib/artist.py", line 60, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/home/jscandal/sw/matplotlib/matplotlib.py3/lib/matplotlib/figure.py", line 1121, in draw
    func(*args)
  File "/usr/lib/python3.4/site-packages/mpl_toolkits/mplot3d/axes3d.py", line 273, in draw
    ax.draw(renderer)
  File "/usr/lib/python3.4/site-packages/mpl_toolkits/mplot3d/axis3d.py", line 264, in draw
    self.axes.transAxes.transform(peparray[0:2, 0]))
ValueError: Expected 2-dimensional array, got 1

Did you follow the suggestion by @tacaswell ? (completely clean out previous installs of matplotlib/mpl_toolkits, then a git clean -fxd, then install). This PR wouldn't cause the issue you are seeing, but mismatched installs of mpl_toolkits and matplotlib would.

@jorgesca Have you rebuilt the master branch? Working a bit on tests the past few days and I have run into problems needing to rebuild the c libraries...

python setup.py develop (or install depending on your preference)

@WeatherGod and @OceanWolf Yes, I think I have followed the suggestion by @tacaswell , but will try once more in case a made a mistake. I'll report back soon

You definitly have more than one version of mpl installed as

 File "/home/jscandal/sw/matplotlib/matplotlib.py3/lib/matplotlib/backends/backend_qt5agg.py", line 74, in paintEvent
    FigureCanvasAgg.draw(self)

vs

  File "/usr/lib/python3.4/site-packages/mpl_toolkits/mplot3d/axes3d.py", line 273, in draw
    ax.draw(renderer)
  File "/usr/lib/python3.4/site-packages/mpl_toolkits/
``

There is some issue which I do not fully understand related to how the namespace packages are handled that puts them in different places.  I strongly suggest using virtual environments to keep things isolated from system python. 

I must have done something wrong before, because the lines3d_demo works now. However, the examples from trendvis continue to raise the same error. Should I open a new issue with the details? I realize now my comments are on the wrong place, I apologize.

Yes, please open a new issue with this.

On Tue, Jul 28, 2015 at 2:33 PM Jorge Scandaliaris notifications@github.com
wrote:

I must have done something wrong before, because the lines3d_demo works
now. However, the examples from trendvis continue to raise the same error.
Should I open a new issue with the details? I realize now my comments are
on the wrong place, I apologize.

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