FIX: maybe improve renderer dance

[jklymak]

PR Summary

Closes #22673

tight_layout and constrained_layout were both calling backend_bases._get_renderer. However, that was probably too low-level, and seems to cause canvas-dpi related flakiness as in #22673, in particular some users were seeing changed dpi because savefig.format was set to a vector backend.

This uses the more robust algorithm in _tight_layout.get_renderer. In particular if fig.canvas already exists and has a renderer, use that because it means the user has already (perhaps interactively) created a canvas. This stops prematurely falling back to a default canvas indicated by savefig.format. This probably mostly worked for folks because the default format is png which is enough like on-screen display that things didn't break.

PR Checklist

Tests and Styling

• Has pytest style unit tests (and pytest passes).
• Is Flake 8 compliant (install flake8-docstrings and run flake8 --docstring-convention=all).

Documentation

• New features are documented, with examples if plot related.
• New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
• API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).
• Documentation is sphinx and numpydoc compliant (the docs should build without error).

[jklymak]

BTW, I have no real way to test this, other than the existing tests, which pass....

[anntzer]

I agree that this is better; likely this "use the cached renderer" logic should always be used even in backend_bases._get_renderer as long as print_method is None (i.e. we're not in a context of savefig with a known format)? That can be fixed lated, though.

[tacaswell]

Seems a bit odd that everything is routed through tight_layout, but this closes at least 2 issues.

[lumberbot-app]

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

git checkout v3.5.x
git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

git cherry-pick -x -m1 9e0eb54fd98bb804f51a74101db88164870a2458

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

git commit -am 'Backport PR #22732: FIX: maybe improve renderer dance'

4. Push to a named branch:

git push YOURFORK v3.5.x:auto-backport-of-pr-22732-on-v3.5.x

5. Create a PR against branch v3.5.x, I would have named this PR:

"Backport PR #22732 on branch v3.5.x (FIX: maybe improve renderer dance)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the Still Needs Manual Backport label once the PR gets merged.

If these instructions are inaccurate, feel free to suggest an improvement.

[anntzer]

Seems a bit odd that everything is routed through tight_layout

As noted above, probably that logic should be pulled out of TL and moved into backend_bases.

[tacaswell]

This backport is odd because a bunch of stuff has moved around.....I'm doing it and will make sure the two linked issues still work.

[jklymak]

As noted above, probably that logic should be pulled out of TL and moved into backend_bases.

#22745 Moves the logic to Figure. The Figure holds the cache, so I'm not clear what we gain from putting the logic in the backends?

[anntzer]

It doesn't really matter to me whether figure or b_bases hold that logic (well, in my view figure is more just for artists and b_bases for canvas/renderer related stuff, but that's no big deal), mostly the point is that having that in t_l doesn't make much sense.