slow rendering with backend_macosx on El Capitan

[efiring]

With a fresh installation of mpl 1.5.1 from Anaconda on a new Macbook Air with El Capitan, there are long delays (several seconds) when rendering a multi-subplot figure based on cut/paste a section of script into an ipython window. This does not occur with the qt4agg backend.
I think we need to ensure the macosx backend is not selected by default, at least in the next mpl release on Anaconda.

[mdboom]

Did this also happen on Mavericks, or is it new to El Capitan? (I'm still on Mavericks, so can confirm one way or the other if you can provide a script to reproduce...)

Is the copy-and-paste into IPython window critical, or does it also happen when running as a script?

[efiring]

It can be demonstrated with the script below, so it does not depend on cut/paste. On a new Macbook Air, part of the plot is displayed, it pauses, and then displays the rest. On Macbook Pro Retina machines, one with Mavericks and the other with Yosemite, it doesn't display anything until the plot is complete. On the Mavericks machine (mine) I can hear the fan and see the power consumption, so evidently it is working rather than waiting. Contrary to my initial guess, I think we are just seeing slower rendering of a very large number of points with the macosx backend compared to any agg backend. I suspect this has always been the case.
Nevertheless, I think this is one more reason for discouraging use of the macosx backend whenever an alternative is available--as it is in any Anaconda installation.

#/usr/bin/env python

import sys
backend = sys.argv[1]

import matplotlib
matplotlib.use(backend)

import matplotlib.pyplot as plt
import numpy as np

fig, axs = plt.subplots(nrows=3)
nw = 101
n = 300000
x = np.arange(n, dtype=float)
y = np.cumsum(np.random.randn(n))
w = np.ones(nw, float) / nw
y = np.convolve(y, w, mode='same')

axs[0].plot(x, y, '.')
axs[1].plot(x, y, '.')
axs[2].plot(x, y, '.')

plt.show()

[tacaswell]

This is not super snappy with Agg

In [12]: %timeit fig.canvas.draw()
1 loops, best of 3: 691 ms per loop

Switching to using pixel markers (',') gives

In [14]: %timeit fig.canvas.draw()
10 loops, best of 3: 123 ms per loop

and using a line (with no markers) gives

In [16]: %timeit fig.canvas.draw()
10 loops, best of 3: 59.3 ms per loop

Using 'o' as the marker is worse

In [18]: %timeit fig.canvas.draw()
1 loops, best of 3: 1.16 s per loop

[efiring]

On my Retina with the '.' marker and macosx:

 In [15]: %timeit fig.canvas.draw()
1 loops, best of 3: 58.9 s per loop

and with qt4agg:

In [15]: %timeit fig.canvas.draw()
1 loops, best of 3: 614 ms per loop

It will be interesting to see how qt5agg handles it when that becomes available; according to @mdboom, it will support the full resolution, while qt4agg is operating in lo-res mode.
Presumably it will be something like the result of saving a png at high dpi:

In [16]: %timeit fig.savefig('test.png', dpi=320)
1 loops, best of 3: 4.26 s per loop

[efiring]

I switched the milestone to "unassigned" because this is not something we can fix in the present macosx backend. The solution will be to use an agg-based backend, either a presently existing one, or a modification of macosx to use agg.

[mdboom]

Fixed by #6178