Unfortunately, the situation with Cairo binaries for my main platform Windows is still difficult.
I could review the files and confirm that the refactoring does not break anything, but can't test much on the Cairo side.
Anyway, I would like to see this and PR#10208 in 2.2. Even if they would not be widely used, it would be good to gain some experience and build upon for 3.0.

fwiw anaconda seems to provide pycairo binaries for Windows (https://anaconda.org/anaconda/pycairo).

Yes, I have seen this, but not tested whether it would be compatible with wx. My interest is in enabling people to embed Matplotlib into wx applications. With wxGlade now also the occasional user should be able to build a wx GUI. Anaconda is something that I would not recommend for this purpose and extracting binaries from Anaconda to 'normal' Python seems also a bit out of scope for most users...

While testing for bug 10418 I tried all wx backends on my Ubuntu 17.10 VM. The old backends seem to be OK, but with the Cairo I got this one:

Traceback (most recent call last):  File "fourier_demo_wx_sgskip.py", line 102, in sliderHandler    self.param.set(value)  File "fourier_demo_wx_sgskip.py", line 64, in set    feedbackKnob.setKnob(self.value)  File "fourier_demo_wx_sgskip.py", line 235, in setKnob    self.canvas.draw()  File "/home/osboxes/.local/lib/python3.6/site-packages/matplotlib-0+unknown-py3.6-linux-x86_64.egg/matplotlib/backends/backend_wxcairo.py", line 44, in draw    buf = surface.get_data()NotImplementedError: Surface.get_data: Not Implemented yet.

According to the documentation of pycairo,get_data() is 'Not yet available in Python 3'.
Maybe there's a workaround or there should be some documentation / warning?

OK, I've found a minor problem in 'backend_wxagg.py' which breaksembedding_in_wx3.py:
Toolbar is not imported frombackend_wx and sofrom matplotlib.backends.backend_wxagg import Toolbar fails.

The original version was:

from .backend_wx import (_BackendWx, FigureManagerWx, FigureCanvasWx,    FigureFrameWx, DEBUG_MSG, NavigationToolbar2Wx, Toolbar)

The new version is lacking the Toolbar import:

from .backend_wx import (    _BackendWx, _FigureCanvasWxBase, FigureFrameWx, NavigationToolbar2Wx)

@tacaswell: would you mind commiting the Toolbar import or should I add it to the examples PR?

surface.get_data was implemented for Py3 in pycairo 1.11.0 (https://pycairo.readthedocs.io/en/latest/changelog.html#v1-11-0) and I would suggest just bumping the min version to it.

That seems a bit agressive in terms of time (<1 yr) but not that aggressive in terms of versions (they are now in 1.16).

I think bumping the minimum on 1.11 and then having packages that can not hit that patch out the new cairo backends.

Ubuntu 17.10 comes with 1.10 in dist-packages. Even after -mpip I ended up with the old version. Now it's working and I can't reproduce why it failed initially. A small difference with the fourier demo: the waveforms are blue while with WxAgg they are red....

@anntzer : I have just checked again on Ubuntu. Indeed the red waveforms are plotted in blue.
Could it be that there's a mismatch in byte ordering? I tried green, which works OK. But blue and red are exchanged.

Almost certainly a byteordering issue. I findhttps://wxpython.org/Phoenix/docs/html/wx.Bitmap.html#wx.Bitmap.FromBuffer a bit sparse in the description of the kind of input needed; I can probably manually work it out but do you know the details there (and spare me some manual testing)?

I think it's actuallyhttps://wxpython.org/Phoenix/docs/html/wx.Bitmap.html#wx.Bitmap.FromBufferRGBA viawx_compat.BitmapFromBuffer = wx.Bitmap.FromBufferRGBA.
Cairo should be ARGB.
If at the same time Cairo and wx differ in LSB vs. MSB, then it would explain things where Alpha is correct and red/blue exchanged. Alpha must be correct as otherwise black or white would fail.

Anyway it seems thatFromBufferRGBA would not create a copy of the memory area. For re-ordering that's required, though.
Maybe tryCopyFromBuffer with formatwx.BitmapBufferFormat_ARGB32:
https://wxpython.org/Phoenix/docs/html/wx.Bitmap.html#wx.Bitmap.CopyFromBuffer
That one explicitely mentions 'native endian order'. If it's still wrong, then a lowlevel re-ordering routine would be nice.

I thinkhttps://github.com/matplotlib/matplotlib/pull/10429/files is a reasonable way to do this because we're going to need to write it ourselves for tkcairo anyways (which also needs a argb32->rgba8888 conversion). (Ultimately I'll just factor it out in a helper function.)

But otherwise something like

diff --git a/lib/matplotlib/backends/backend_wxcairo.py b/lib/matplotlib/backends/backend_wxcairo.pyindex 71a6831c7..337b5b2ea 100644--- a/lib/matplotlib/backends/backend_wxcairo.py+++ b/lib/matplotlib/backends/backend_wxcairo.py@@ -44,13 +44,8 @@ class FigureCanvasWxCairo(_FigureCanvasWxBase, FigureCanvasCairo):         self._renderer.set_ctx_from_surface(surface)         self._renderer.set_width_height(width, height)         self.figure.draw(self._renderer)-        buf = np.frombuffer(surface.get_data(), dtype="uint8").reshape((height, width, 4))-        if sys.byteorder == "little":-            b, g, r, a = np.rollaxis(buf, -1)-        else:-            a, r, g, b = np.rollaxis(buf, -1)-        rgba8888 = np.dstack([r, g, b, a])-        self.bitmap = wxc.BitmapFromBuffer(width, height, rgba8888)+        self.bitmap = wx.EmptyBitmap(width, height).CopyFromBuffer(+            surface.get_data(), wx.BitmapBufferFormat_ARGB32)         self._isDrawn = True         self.gui_repaint(drawDC=drawDC, origin='WXCairo')

seems to work too.