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
Transparent rcparams #2390
Transparent rcparams #2390
Conversation
Closes issue matplotlib#2388
is passed to `savefig`, the patch colors are restored on the screen after saving.
@@ -563,7 +563,9 @@ def draw(): | |||
@docstring.copy_dedent(Figure.savefig) | |||
def savefig(*args, **kwargs): | |||
fig = gcf() | |||
return fig.savefig(*args, **kwargs) | |||
res = fig.savefig(*args, **kwargs) | |||
draw() # need this if 'transparent=True' to reset colors |
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.
I'm not sure I understand why this is needed. Forgetting the rcParam
, what's the difference if I just pass tansparent=True
to savefig
manually?
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.
This change is only tangentally related to the rcParams work.
I noticed while testing with transparent=True
in an interactive backend (qt4) that after the save the background patch was still invisible. The savefig
code does restore the correct colors, but the display never got updated.
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.
I'm not that comfortable with this change. A quicker alternative might be to capture a frame buffer and fire it back at the canvas. @mdboom do you have any insight?
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.
Would it be better to use draw_if_interactive
? Which now that I think a bit more about it is what I should have done to begin with.
Aside from a little clarification needed on my part, I'm all for this change. Thanks @tacaswell. |
As suggested by @dmcdougall
@@ -59,6 +59,9 @@ original location: | |||
thus `colorbar.ColorbarBase.outline` is now a | |||
`matplotlib.patches.Polygon` object. | |||
|
|||
* The rcParams `savefig.transparent` has been added to control | |||
default transparency when saving figures. |
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.
Since this is actually a new feature, it should probably be added to whats_new.rst as well.
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.
done.
👍 |
I'm jumping in late, sorry. I think more work is needed to clean this up. The basic background and edge color handling is being done in backend_bases, FigureCanvasBase.print_figure(). Then transparency is handled as a special case in Figure.savefig, and one more fiddle for transparency (but being done regardless of whether it is needed) is in pyplot. Some rationalization and consolidation is needed. |
Oh my. I thought this was a simple addition to the codebase. I should have left this open for a little longer to garner feedback before merging. Sorry if I've stepped on any toes here. Shall I go ahead and open a separate issue regarding the call to |
OK. But the issue is not really the call to draw(), it is the overall factoring: I think printed transparency should be handled together with the rest of the print-versus-display shuffle, which is in print_figure, and any extra draw operation following the printing operation should be executed only when it is actually needed. This is my impression based on a very quick look, so I might be missing something. (Of course if I looked long and hard, I might still miss something...) |
Agreed with @efiring above. |
Addresses issue #2388