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

import matplotlib.pyplot as plt
from matplotlib.figure import Figure

fig = 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 to FigureManagerBase.destroy(). However, that is currently empty and not called from any of the specific FigureManagerX.destroy(), so we'd need to inject super().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 of ENH: 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 the fig.canvas is a FigureCanvasBase again.

Note: the failing tests are in test_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 to FigureCanvasBase, 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 a FigureCanvasBase (which imlies it can be saved with savefig, 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 to FigureManagerBase.destroy(). However, that is currently empty and not called from any of the specific FigureManagerX.destroy(), so we'd need to inject super().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 their destroy(). 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 the canvas.get_renderer() calls from the tests, but that is a later problem.

To expand, get_renderer() is impremented on Agg so if we create a figure with pyplot in the tests it gets FigureCanvasAgg as the canvas, but when we close the figure it now goes back to FigureCanvasBase which does not have that method, however if we simply do not ask for the renderer and pass it to methods, they will all internally sort out what the correct renderer is to use based on the currently attached canvas.

I'm still seeing failures locally but given that CI passes without the last commit, we may want to drop that one (I'm willing to push commits to Tim's branch, but not force push without explicit permission).

I'm seeing timeout errors (including what looks like an infinite hang!) locally so I fear that I am the "lucky" developer who can reproduce our random hangs on CI locally.

@tacaswell you are welcome to force-push

I think this is ready for review (the one failure so far is an invalid DISPLAY which I have seen at least once recently)

My figure keeps growing...

Python 3.12.5 | packaged by conda-forge | (main, Aug  8 2024, 18:36:51) [GCC 12.4.0]
Type 'copyright', 'credits' or 'license' for more information
IPython 8.26.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import matplotlib.pyplot as plt
   ...: from matplotlib.figure import Figure
   ...: 
   ...: fig = Figure()
   ...: ax = fig.subplots()
   ...: ax.plot([0, 2])
   ...: plt.figure(fig)
   ...: plt.show()
   ...: 

In [2]: plt.figure(fig)
Out[2]: <Figure size 800x600 with 1 Axes>

In [3]: plt.show()

In [4]: plt.figure(fig)
Out[4]: <Figure size 1000x750 with 1 Axes>

In [5]: plt.show()

In [6]: plt.figure(fig)
Out[6]: <Figure size 1250x937.5 with 1 Axes>

In [7]: plt.show()

In [8]: plt.figure(fig)
Out[8]: <Figure size 1850x960 with 1 Axes>

In [9]: plt.show()

It seems to be the show() that increases the figure size, and also the dpi. I am using QtAgg.

@rcomer Do you have a hi-dpi screen an 125% scaling?

Heads up / side-topic: In my example, I found it a bit annoying that I have to plt.figure(fig); plt.show() to re-show a figure.
Therefore, I'm considering whethe fig.show() could do an automatic plt.figure(fig) in the background. I haven't thought through all the details but that would allow for a workflow without touching pyplot from the user side, e.g.

fig = Figure()
ax = fig.subplots()
ax.plot([1, 2, 3])
fig.show()

Pyplot would still be used in the background but registering/deregistering would keep a clean state.

But that discussion is for a followup. I'm mentioning this just in case you were also stumbling over plt.figure(fig); plt.show(). Let's keep this PR focussed.

My display settings look like this:

(I did have the laptop plugged into the TV earlier, but I have reproduced on the built-in screen after a reboot)

I cannot repoduce the behavior here - figure size stays the same (pyqt 5.15.9; unscaled screen).

Does it happen with other (Agg-based) backends as well, e.g. tkagg?