Usingmpl.use('Qt5Agg') works as expected on my hi-dpi mac for resizing and dragging the window around.

Usingmpl.use('Qt5Cairo') works as expected on my hi-dpi mac, except redraws are quite slow, so moving or resizing are quite laggy compared to Qt5Agg.

I just used a randomish bit of test code that happened to have a small pcolor in it:

importmatplotlibasmplmpl.use('Qt5Cairo')importmatplotlib.pyplotaspltimportmatplotlib.tickerastickerimportnumpyasnpvalues=np.random.rand(290,20)values[:26, :]=np.NaNvalues[ [57,239,253], :]=np.nanvalues=np.ma.masked_invalid(values)h,w=values.shape#h=262, w=20fig,ax=plt.subplots(figsize=(9,7))#fig, ax = plt.subplots()y=np.arange(0,290.5)x=np.arange(0,20.5)pcm=ax.pcolormesh(x,y,values)fig.colorbar(pcm)plt.xticks(np.arange(w),list('PNIYLKCVFWABCDEFGHIJ'))plt.show()

EDIT: Bumping the 290x20 pcolor up to 290x290 madeQt5Cairo completely unusable; It took about 60 seconds to even finish the first render.Qt5Agg was fine.

The current (pure-python) cairo backend implementation is not optimized for speed at all (and again, it is not thereal point of this PR :-)). You can play with#8787 if you want to improve the performance a bit, but really the way to do this is to write it in C(++)... which I did :)

Great! Just wanted you to know that it worked, but wasn't blazingly fast. and of course that you didn't seem to breakQt5Agg for me at least, including the DPI support. I'll spend a bit of time w/ the actual code to make sure I follow the changes and post a proper review soon.

I'm a little hesitant to merge this if@anntzer is busy in the next week and it breaks a lot of things....

I am comfortable enough with this part of the code to not be worried about this.

Not sure if it's really an argument but you should in general feel free to revert my PRs if they break stuff and I don't have the bandwidth to take care of the breakage.

Thanks for helping me getting this in! 😃

Thesuper(FigureCanvasAgg, self).draw() inFigureCanvasAgg breaks the current WxAgg backend implementation. It may break other things as well.

Thedraw() method in FigureCanvasWxAgg callsFigureCanvasAgg.draw().
Then in turnFigureCanvasAgg callssuper(FigureCanvasAgg, self).draw() which here isFigureCanvasWx.draw(), i.e. the non-Agg version.

ReplacingFigureCanvasAgg.draw(self) withself.figure.draw(self.get_renderer()) inbackend_wxagg.FigureCanvasWxAgg.draw does fix things for me and seems the right thing anyway. I'm not sure about side effects, though.

But if ever there was code to callFigureCanvasAgg.draw, then things would fail assuper finds the wrong method.

The inheritance for the wx backends:

class FigureCanvasWxAgg(FigureCanvasAgg, FigureCanvasWx)class FigureCanvasWx(FigureCanvasBase, wx.Panel)class FigureCanvasAgg(FigureCanvasBase)

Without multiple inheritance, would the super class ofFigureCanvasAgg not be theFigureCanvasBase? Sosuper usually would not find the GUI class, right? I'm not familiar with the other backends (and also not yet really with the wx ones). WouldFigureCanvasAgg.draw() ever be called if the derived classes usefigure.draw(renderer)?

Can confirm the issue.
Basically this is due to the confusion between FigureCanvasWx being a base class for Wx widgets and the class specifically for RendererWx (if it was just a base class then it should not set the renderer and let the rendering subclass take care of that). In any case RendererWx is slated for removal in 2.2 and I think the correct solution is just to do the removal and rewrite RendererWx accordingly.

In the meantime the following patch seems to work

diff --git a/lib/matplotlib/backends/backend_wx.py b/lib/matplotlib/backends/backend_wx.pyindex 775107a08..85531d956 100644--- a/lib/matplotlib/backends/backend_wx.py+++ b/lib/matplotlib/backends/backend_wx.py@@ -721,7 +721,9 @@ class FigureCanvasWx(FigureCanvasBase, wx.Panel):         previously defined renderer if none is specified.         """         DEBUG_MSG("draw()", 1, self)-        self.renderer = RendererWx(self.bitmap, self.figure.dpi)+        from .backend_wxagg import FigureCanvasWxAgg+        if not isinstance(self, FigureCanvasWxAgg):+            self.renderer = RendererWx(self.bitmap, self.figure.dpi)         self.figure.draw(self.renderer)         self._isDrawn = True         self.gui_repaint(drawDC=drawDC)diff --git a/lib/matplotlib/backends/backend_wxagg.py b/lib/matplotlib/backends/backend_wxagg.pyindex 8383f50cd..482002cbd 100644--- a/lib/matplotlib/backends/backend_wxagg.py+++ b/lib/matplotlib/backends/backend_wxagg.py@@ -37,16 +37,11 @@ class FigureCanvasWxAgg(FigureCanvasAgg, FigureCanvasWx):     size.     """ -    def draw(self, drawDC=None):-        """-        Render the figure using agg.-        """-        DEBUG_MSG("draw()", 1, self)-        FigureCanvasAgg.draw(self)-+    def gui_repaint(self, drawDC=None, origin='WXAgg'):         self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(), None)         self._isDrawn = True-        self.gui_repaint(drawDC=drawDC, origin='WXAgg')+        super(FigureCanvasWxAgg, self).gui_repaint(+            drawDC=drawDC, origin=origin)      def blit(self, bbox=None):         """

Note that the slightly ugly instance check in FigureCanvasWx.draw can be removed once the Wx backend is likewise removed.

PS: I think this warrants a release critical issue.@DietmarSchwertberger can you open it?

Wouldn't it be better to implement aget_renderer() method for theFigureCanvasWx instead of using the instance check?

This here is not exactly peformance-optimized, but should actually behave the same as before:

class FigureCanvasWx:    def get_renderer(self):        self.renderer = RendererWx(self.bitmap, self.figure.dpi)        return self.renderer    def draw(self, drawDC=None):        self.figure.draw( self.get_renderer() )        self._isDrawn = True        self.gui_repaint(drawDC=drawDC)

Later this year, I would like give it a try whether theFigureCanvasWx code could be used to render to aMetaFileDC. Having direct WMF/EMF export again would be nice on Windows. As of now, for rendering to a bitmap and then pasting to the screen, I agree that it does not have an added value.

Regarding my question from above whetherFigureCanvasAgg.draw() would be called at all.

I had a look atQTAgg.
When the application callscanvas.draw(), actuallyFigureCanvasAgg.draw() is called.
This, after drawing, in turn callssuper(FigureCanvasAgg, self).draw() which is actuallyFigureCanvasQT.draw() due to inheritance.
Somehow I don't like such a setup where calls to methods of the same name go back and forth between the classes. I would prefer a more direct approach with e.g.FigureCanvasQTAgg.draw andFigureCanvasAgg.draw calling eitherself.figure.draw(self.get_renderer()) orFigureCanvasAgg.render. The locking could be done insidefigure.draw().
Well, I don't care too much as this does not touch the Wx backends, but in the long run it would nice to have the same architecture for all (GUI and non-GUI) backends.

Thedraw chain seems like pretty-standard OO style. I think it helps make supporting multiple rasterization backends (Agg, cairo, native, ...) under each GUI framework easier.

Regarding the first point:
I guess defining get_renderer on FigureCanvasWx works fine too (haven't looked in depth). The real question is whether we want to keep RendererWx around. A quick look athttps://wxpython.org/Phoenix/docs/html/wx.BitmapType.enumeration.html#wx-bitmaptype doesn't show EMF/WMF support (but I may be missing something)? Does Pillow support EMF/WMF?

The RendererWx seems to call standard wx.DC Draw methods. So it should be possible to render to a MetaFileDC. The point is to get high quality vector graphics. I would not place bitmap images in e.g. datasheets for publication. So Bitmap or Pillow do not help here. (At the moment the only way is to convert SVG graphics, which is working better with the recent Inkscape releases.)

(fwiw it may be ultimately possible to generate emf/wmf files with the cairo backend as well viahttps://cairographics.org/manual/cairo-Win32-Surfaces.html +https://msdn.microsoft.com/en-us/library/windows/desktop/ms535284(v=vs.85).aspx) (but that'll wait for mplcairo to be a bit more settled first...)

We used to have a dedicated emf backend, but it broke and was removed in 2013 (#2026).

I think there exists a third-party EMF backend, but google is failing me.

I did use the EMF backend a long time ago and did even use it after removal, but it did not clip the lines IIRC. I did not find anything else at that time and so I switched to SVG->Inkscape->WMF...

By default Cairo-Win32-Surfaces seem to be 'raster surface type', even though for printing there seems to be a vector surface. Given the availability of wx vs. Cairo binaries on Windows, a WxEMF would be nicer.

This is not high-priority, though, as I only create datasheets once or twice a year and often I need to post-process them anyway...

Back to the failure we have on master, which of the proposed solutions do we want to go with?

We are now over a week late on our target for 2.2rc1 so I'm happy with any solution that un-breaks the master branch, we can iterate as needed later.

I would suggest to take Antony's code with my modification forget_renderer.
I could test this locally on Windows and Ubuntu and upload a pull-request today or at latest tomorrow.
(I'm not yet comfortable with writing to master myself...)

Update: with the merged Cairo PR, thesuper(FigureCanvasAgg, self).draw() is a no-op as it calls the empty implementation fromFigureCanvasBase.
I think that this fixes the issue already and that's maybe why Antony has not seen the failure initially.
I will do some more testing, also with the non-Agg backend.

@DietmarSchwertberger We never write to master directly, everything must go through PRs with usually two other devs accepting the PR (the second one committing it). Seehttps://matplotlib.org/devel/coding_guide.html#pr-review-guidelines (although I guess this is not explicitly written there...).