I was hoping I could modify the figure and show again, but that does not seem to be the case

importmatplotlib.pyplotaspltfrommatplotlib.figureimportFigurefig=Figure()ax=fig.subplots()ax.plot([0,2])plt.figure(fig)plt.show()ax.set_title('A cool line')plt.figure(fig)plt.show()

No title is shown 😕

This would also close#19956.

Showing again now works properly. When destroying a figure manager, the figure's canvas is reset to a FigureCanvasBase.

Technical questions:

• I've added resetting the canvas to the specific manager's destroy method (currently only implemented for Qt). This means, I have to add it to all gui-specific managers. But I feel it belongs there: The gui-specific managers replace the FigureCanvasBase when they are created, so they should undo this when they are destroyed. - One could in theory add it toFigureManagerBase.destroy(). However, that is currently empty and not called from any of the specific FigureManagerX.destroy(), so we'd need to injectsuper().destroy()` calls and then I think I'd rather keep it explicit. - Feedback welcome.
• I've also not a good idea how to test this, i.e. the equivalent ofENH: Allow to register standalone figures with pyplot #29855 (comment). I suspect, I need to use a proper GUI backend with a real window and then somehow get the window to close. - Can this be done in tests? - After that, I could check that thefig.canvas is aFigureCanvasBase again.

Note: the failing tests are intest_interactive_backend, which saves the figure to file, closes it, and then saves it to file again, expecting exactly the same output.

This is now no longer the case, as closing the figure resets the canvas toFigureCanvasBase, i.e. the images are genereated through different canvases -FigureCanvasBase and the backend-specific canvas, which do not necessarily have pixel-identical output. An example diff looks like this:

How should we handle this? I'm inclined to say that the previous expectation is no longer justified, and it makes sense that the canvas is reset. Should we try to fix this with tolerances? Or don't we need this image test at all anymore and instead it is sufficient to test that the figure has again aFigureCanvasBase (which imlies it can be saved withsavefig, but we don't have to test the contents? Or are there other approaches?

It's a bit strange that the end png result is not the same, as both should ultimately go through Agg for rasterizing... It would be nice to figure out what is going wrong, but I agree this isn't a blocker.

Failing tests are

FAILED lib/matplotlib/tests/test_backends_interactive.py::test_interactive_backend[toolbar2-MPLBACKEND=qtagg-QT_API=PyQt5-BACKEND_DEPS=PyQt5]FAILED lib/matplotlib/tests/test_backends_interactive.py::test_interactive_backend[toolbar2-MPLBACKEND=qtcairo-QT_API=PyQt6-BACKEND_DEPS=PyQt6,cairocffi]FAILED lib/matplotlib/tests/test_backends_interactive.py::test_interactive_backend[toolbar2-MPLBACKEND=qtcairo-QT_API=PySide6-BACKEND_DEPS=PySide6,cairocffi]FAILED lib/matplotlib/tests/test_backends_interactive.py::test_interactive_backend[toolbar2-MPLBACKEND=qtcairo-QT_API=PyQt5-BACKEND_DEPS=PyQt5,cairocffi]FAILED lib/matplotlib/tests/test_backends_interactive.py::test_interactive_backend[toolbar2-MPLBACKEND=qtcairo-QT_API=PySide2-BACKEND_DEPS=PySide2,cairocffi]

and the same again for toolmanager, which I left out for simplicity. So all cairocffi tests fail and addtionally the qtagg-PyQt5 test. But the agg-based tests for PyQt6, PySide2 and PySide6 pass. Interestingly, the qtagg-PyQt5 test passes on my local machine.

The above diff image was from qtcairo-PyQt5.

At least for the cairo tests this is understandable: if you reset to FigureCanvasBase, then they will now rasterize using agg, whereas they rasterized with cairo prior to that. I guess that's probably fine?
No idea about the qt5agg test, though.

• I've added resetting the canvas to the specific manager's destroy method (currently only implemented for Qt). This means, I have to add it to all gui-specific managers. But I feel it belongs there: The gui-specific managers replace the FigureCanvasBase when they are created, so they should undo this when they are destroyed. - One could in theory add it toFigureManagerBase.destroy(). However, that is currently empty and not called from any of the specific FigureManagerX.destroy(), so we'd need to injectsuper().destroy()` calls and then I think I'd rather keep it explicit. - Feedback welcome.

I prefer adding doing this via super() calls: for the benefit of third-parties, it is relatively easier to document "one needs to call super().destroy() in subclasses" rather than "one needs to do this and that" (restore the default canvas, but who knows what else can change in the future).

My thought was that the specific FigureManager* classes override the canvas in their__init__ and hence they should undo what they did in theirdestroy(). But one could also argue that resetting to the base canvas is a universal property of destroying any manager.

I took the liberty of fixing one of the tests. We probably should purge all of thecanvas.get_renderer() calls from the tests, but that is a later problem.

I spot-checked this on OSX and it seems work as expected:

• showing figure
• re-showing figure
• switching the canvas back toFigureCanvasBase
• withplt.ioff() andplt.ion()
• mouse/keyboard events work with reshown figures

Thank you@timhoffm !

I'm super stoked we landed this as this has been a low-key goal of mine for a while now. I'm also very happy that the actual implementation was way simpler and less invasive than the direction I was going.

🎉😀🍾🥂