-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Deprecate the dryrun parameter to print_foo(). #14134
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The print_foo() methods of all backends (that implement saving to a given format -- print_svg saves to svg, etc.) all have an undocumented `dryrun` parameter that effectively means "don't actually do the drawing; just set the _cachedRenderer attribute on the figure" with the intent of using that renderer object to determine the figure tight bbox for saving with bbox_inches="tight". - This behavior is not actually implemented for the pdf backend, so saving to pdf with bbox_inches="tight" will currently fully walk the artist tree twice. - This is a parameter that needs to be reimplemented again and again for all third-party backends (cough cough, mplcairo). Instead, we can extract that renderer object by fiddling with Figure.draw (see implementation of _get_renderer), which may not be the most elegant, but avoids having to reimplement the same functionality across each backend. This patch also found that Table's window_extent is incorrect until a draw() is performed. Fix that problem by correctly setting the table's text positions in get_window_extent().
@@ -458,6 +458,7 @@ def get_children(self): | |||
|
|||
def get_window_extent(self, renderer): | |||
"""Return the bounding box of the table in window coords.""" | |||
self._update_positions(renderer) |
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.
Could you add a quick test for the issue solved by this change?
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.
A few tests in test_bbox_tight fail without it (they test tight-bboxing tables).
@anntzer @tacaswell @dstansby - This has broken some functionality in astropy's WCSAxes, specifically when creating plots with from astropy.wcs import WCS
import matplotlib.pyplot as plt
wcs = WCS()
fig = plt.figure(figsize=(3, 3))
ax = fig.add_axes([0.25, 0.25, 0.5, 0.5], projection=wcs, aspect='equal')
ax.set_xlim(0, 10000)
ax.set_ylim(0, 10)
fig.savefig('test.png', bbox_inches='tight') In this case, the final bounding box is the one as if the aspect ratio had not been set to equal. It makes some kind of sense that this PR would affect this since I seem to recall that Matplotlib will actually first draw the figure without taking into account the equal aspect then update the plot to take into account the aspect, and somehow for WCSAxes this means that it remembers the bounding box before the aspect ratio is actually updated internally. My question here is whether it's expected that this PR would have the potential to break subclasses of Axes that overwrite |
I've managed to narrow this down to the following minimal example: import matplotlib.pyplot as plt
from matplotlib.axes import Axes
class MyAxes(Axes):
def get_tightbbox(self, renderer, *args, **kwargs):
return self.get_window_extent(renderer)
fig = plt.figure(figsize=(3, 3))
ax = fig.add_axes(MyAxes(fig, [0.25, 0.25, 0.5, 0.5], aspect='equal'))
ax.set_xlim(0, 10000)
ax.set_ylim(0, 1000)
fig.savefig('test.png', bbox_inches='tight') In WCSAxes we customize |
I think get_tightbbox needs to call apply_aspect. I’m still confused about which way this broke. Is the new image too big or too small? Note that get_window_extent doesn’t include any decorators or artists on the axes. Usually get_tightbbox does. Note also that we have changed the default artists included to include all axes artists so astropy may want to redo its method of including/excluding artists. Is the reason this PR broke things because it. Allied the draw twice? I actually think this will end up being derigeur for all the tight and constrained layout calculations. Not very efficient but if you are asking for automated layout you will get better results if you burn a few cpu cycles. |
The new output image is too large (the example code in my last comment above shows the issue). Good to know about including all artists, I'll investigate whether updating |
It looks like https://github.com/matplotlib/matplotlib/pull/14134/files#diff-504c288d675954e4e24de83a19242f4dL2046 was doing more than just getting the renderer (as it was actually triggering the draw methods which updates the bounding boxes). I am inclined to treat this as an un-intentional and insufficiently warned backward incompatibility break that should be fixed on our side, but one that should be made eventually (and I don't see how to warn this one effectively). I think if @astrofrog finds a way to fix WCSAxes without too much pain and there is a release of WCSAxes before 3.2 comes out (which at this point will be Nov - Dec of 2019) we should leave this in, otherwise we should back this out for another cycle to give down stream libraries more time to adjust. At a minimum this needs more verbiage in the API changes docs warning about this problem. |
The breakage was definitely unintentional. I think we can fix this by adding, after the
line, a call to
? Happy to provide a PR if that fixes WCSAxes. |
Changing: renderer = _get_renderer(
self.figure,
functools.partial(
print_method, dpi=dpi, orientation=orientation)) to renderer = _get_renderer(
self.figure,
functools.partial(
print_method, dpi=dpi, orientation=orientation))
self.figure.draw(renderer) Seems to fix the WCSAxes issue. I'll still take a look at whether we can adjust our code to not have to overload |
The print_foo() methods of all backends (that implement saving to a
given format -- print_svg saves to svg, etc.) all have an undocumented
dryrun
parameter that effectively means "don't actually do thedrawing; just set the _cachedRenderer attribute on the figure" with the
intent of using that renderer object to determine the figure tight bbox
for saving with bbox_inches="tight".
saving to pdf with bbox_inches="tight" will currently fully walk the
artist tree twice.
all third-party backends (cough cough, mplcairo).
Instead, we can extract that renderer object by fiddling with
Figure.draw (see implementation of _get_renderer), which may not be the
most elegant, but avoids having to reimplement the same functionality
across each backend.
This patch also found that Table's window_extent is incorrect until a
draw() is performed. Fix that problem by correctly setting the table's
text positions in get_window_extent().
PR Summary
PR Checklist