Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
FIX: maybe improve renderer dance#22732
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
BTW, I have no real way to test this, other than the existing tests, which pass.... |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Seems a bit odd that everything is routed through tight_layout, but this closes at least 2 issues.
Owee, I'm MrMeeseeks, Look at me. There seem to be a conflict, please backport manually. Here are approximate instructions:
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 If these instructions are inaccurate, feel free tosuggest an improvement. |
As noted above, probably that logic should be pulled out of TL and moved into backend_bases. |
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. |
Merge pull requestmatplotlib#22732 from jklymak/fix-renderer-danceFIX: improve cached renderer dance(cherry picked from commit9e0eb54)The changes had to be moved to figure.py due to a major refactoring that willbe released in 3.6 that is already on main.
#22745 Moves the logic to |
…-v3.5.xBackport PR#22732: FIX: maybe improve renderer dance
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. |
Uh oh!
There was an error while loading.Please reload this page.
PR Summary
Closes#22673
tight_layoutandconstrained_layoutwere both callingbackend_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 becausesavefig.formatwas set to a vector backend.This uses the more robust algorithm in
_tight_layout.get_renderer. In particular iffig.canvasalready 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 bysavefig.format. This probablymostly worked for folks because the defaultformatispngwhich is enough like on-screen display that things didn't break.PR Checklist
Tests and Styling
pytestpasses).flake8-docstringsand runflake8 --docstring-convention=all).Documentation
doc/users/next_whats_new/(follow instructions in README.rst there).doc/api/next_api_changes/(follow instructions in README.rst there).