Ideally, I guess the goal of separating the rasterizer and the GUI (which would be great) would be attained once the qtagg backend can simply be class FigureCanvasQTAgg(FigureCanvasAgg, FigureCanvasQT): pass (with everything coming through multiple inheritance) and the (builtin) qtcairo backend can likewise be class FigureCanvasQTCairo(FigureCanvasCairo, FigureCanvasQT): pass.

class FigureCanvasQTAgg(FigureCanvasAgg, FigureCanvasQT): pass (with everything coming through multiple inheritance)

Maybe I'm a bit too ambitious, but I see the existence of FigureCanvasAgg as a failure to define the interface between FigureCanvas and Renderer clearly enough (or maybe I haven't fully grasped the reason for FigureCanvas to be renderer specific - a generic figure canvas can still forward on specific rendering requests, so no API change needed.

I do think that it probably requires a RasterisingRenderer base class though, and I'm not clear what we do when a renderer can be both rasterising and a vector renderer (like your cairo renderer).

Ultimately, in that world the abstractions would be clear, and you would construct canvas = FigureCanvasQt(renderer_type=RendererAgg) (or equivalent at the _Backend level). I'm not sure if we would actually be able to get that far, so your multiple inheritance proposal may be the necessary approach pragmatically.

You need to have a FigureCanvasAgg because you need to be able to render figures in a headless context. If anything, if switching to non-multiple-inheritance, FigureCanvasQTAgg() should be replaced by something like FigureCanvasAgg(gui=QtGui) rather than the other way round. But (even though I agree that MI is messy) I think it would be a quite nasty refactor to get there.

(I guess alternatively you could only have a RendererAgg and let figures not always have a canvas but sometimes only have a renderer, but that would be a pretty big refactor too.)

(I guess alternatively you could only have a RendererAgg and let figures not always have a canvas but sometimes only have a renderer, but that would be a pretty big refactor too.)

Agreed. This isn't desirable (and tells us that the renderer and the figure canvas abstractions are slightly wrong).

You need to have a FigureCanvasAgg because you need to be able to render figures in a headless context.

I've been processing what you said here, and I think I'm not 100% I can understand the reasoning. The canvas is the thing that the renderer draws onto. Rasterising renderers can all draw onto their own internal pixel buffer, and then a standard interface can be used to put such a raster onto the appropriate canvas, right?

If I understand the problem is that some renderers can draw to multiple canvas types (not just rasters), and that therefore some will want to implement specific print_{fmt} methods. As I understand, the Antigrain library has no such functionality - you just get raw pixel buffers, and therefore technically, I think there should be a generic FigureCanvas which delegates to the appropriate PIL calls (as per the FigureCanvasAgg today). Clearly FigureCanvasCairo would still need to exist such that it can implement the appropriate print_ methods to be able to leverage the functionality of cairo, but it would not be necessary to use the FigureCanvasCairo for graphical backends using cairo for rasterisation.

In summary:

• A FigureCanvasForRasterRenderer (or some other name) would exist, and it would implement all of the appropriate print_{fmt} methods, with those simply taking raw pixel values and calling PIL (or equivalent)
• A FigureCanvasQt, FigureCanvasGTK, FigureCanvasTK, etc. which takes raw pixels from a RasterisingRenderer (which the canvas builds from the factory given at __init__), and puts it on the appropriate GUI component, as well as handling events / coord transforms etc. from the specific windowing manager.
• A FigureCanvasCairo which implements print_svg and other such raster and vector formats, by calling draw on the figure with the right renderer type. This figure canvas is tightly bound to the cairo renderer (i.e. it won't work with an Agg renderer).

With an architecture such as this, Agg, Cairo and other rasterising renderers 😉 can all share the same GUI implementations, from what I can see. Yet it is possible for specific backends to refine the output (headless) formats, if they so exist (e.g. in cairo).

Your design sounds like a good idea, but there are still some issues with print_foo dispatch. For example, currently if I set the backend to mplcairo.qt (FigureCanvasQt(rasterizer=MplCairoRenderer) in your API?) and call savefig to a svg format, the svg file will be generated with mplcairo. In your proposed design, FigureCanvasQt probably(?) does not expose a print_svg method (unless you dynamically add those based on whatever the underlying renderer provides?) so matplotlib would just fall back to its default svg-able backend (which is the default svg backend).
Clearly such issues are fixable (by dynamically providing print_foo, as noted above, or by re-designing the format-to-backend dispatch algorithm), I'm just mentioning them there because they'll require some thought.

In any case, the patch looks correct to me, but I am not absolutely sure we can drop the various qt backcompat-related codes yet (possibly, I just haven't looked).

FWIW, I checked with pyqt6 locally and it was fine (as too was pyside and pyqt5).

Also, as a side point: another idea I had was that we could also try setting up GUI backends that are not based on a raster renderer, but on vector backends, and uses the rasterizer provided by the GUI package: it should be possible to plug a svg output into a QSvgWidget (https://doc.qt.io/qt-6/qsvgwidget.html) or a Tk SVG photoimage (https://core.tcl-lang.org/tips/doc/trunk/tip/507.md), or a pdf output into a QPdfView (https://doc.qt.io/qt-6/qpdfview.html).