When these are finally removed it's no longer possible to define a style with a on display figure facecolor that is different from the saved one right? So this will change the on-display of classic style to no longer have a gray facecolor?

@jenshnielsen Are you advocating for the ability to have a style like that?

I wonder if a savefig.style rcParam is something that would be easy to impliment. i.e. when savefig is called, the figure gets drawn in a different style context. That would be less of a "special case" bunch of code.

Right now styles are only applied at figure/axes creation time, not at draw time, so savefig.style wouldn't help (what you'd really need is artist style sheets, but that's a much more complicated project).

The "classic" style can be recovered by setting the patch background to transparent and the widget background to gray (see #9698 where I set it to white). This admittedly requires backend-dependent code, but I always assumed that the reason for the gray background in the classic style was exactly due to trying to match the widget color... In any case I agree it is less simple, and thus a tradeoff to consider.

The gray background was more than likely because that’s what matlab did. But I don’t think that’s a good reason for us to carry this millstone around.

fwiw the widget color can be set in a backend dependent fashion (except for gtk2, which I haven't tested, but should be easy too?) as follows:

from pylab import *

rcParams["figure.facecolor"] = (0, 0, 0, 0)
if "qt" in get_backend().lower():
    gcf().canvas.setStyleSheet("QWidget {background: red;}")
elif "gtk" in get_backend().lower():
    from gi.repository import Gtk
    css = Gtk.CssProvider()
    css.load_from_data(b"* {background-color: red;}")
    gcf().canvas.get_style_context().add_provider(
        css, Gtk.STYLE_PROVIDER_PRIORITY_USER)
elif "tk" in get_backend().lower():
    gcf().canvas._tkcanvas.configure(background="red")
elif "wx" in get_backend().lower():
    gcf().canvas.SetBackgroundColour("red")
gca()
show()

(replace red by your favorite color, of course)
For gtk3{agg,cairo}, #10297 and #10298 need to be merged first.

punted to 3 as I think this needs a bit more thought about consequences.

So if you have a white figure and want to save it transparently instead of

plt.savefig("name", transparent=True)
plt.show()

you would need to write

ofc = plt.gcf().get_facecolor()
ofca = []
plt.gcf().set_facecolor((1,1,1,0))
for ax in plt.gcf().axes:
    ofca.append(ax.get_facecolor())
    ax.set_facecolor((1,1,1,0))
plt.savefig("name")
plt.gcf().set_facecolor(ofc)
for ax,fc in zip(plt.gcf().axes):
    ax.set_facecolor(fc)
plt.show()

Or, inversely, if all figures are transparent by default and you wanted to have a white background, instead of

plt.savefig("name", facecolor="w")
plt.show()

you would need

ofc = plt.gcf().get_facecolor()
ofca = []
plt.gcf().set_facecolor("w")
for ax in plt.gcf().axes:
    ofca.append(ax.get_facecolor())
    ax.set_facecolor("w")
plt.savefig("name")
plt.gcf().set_facecolor(ofc)
for ax,fc in zip(plt.gcf().axes):
    ax.set_facecolor(fc)
plt.show()

Is it 9 extra lines for saving a simple figure or am I missing something here?

We could definitely come up with a better API to do these manipulations (and even make sure that they are included before removing the functionality from savefig), e.g.

with force_style({"figure.background": "w"}): fig.savefig(...)

etc. (yes, the style is currently not applied to existing figures).

The point is that it doesn't really make sense to duplicate all the figure-and-axes manipulation API as keywords to savefig.

Edit: or

with properties_cm(fig, facecolor=...): fig.savefig(...)

(where properties_cm is like setp, but as a contextmanager) which works around the delayed style application problem.

See also #7619 for someone being confused by the duplication.

@anntzer is this still something you want to pursue? Not entirely sure a new context manager is any better than just passing kwargs to fig.savefig(), and I guess I agree w @ImportanceOfBeingErnest that this deprecation would make for a lot of user pain if they need to change things at print time. Though counter to that, I'm not sure why folks want to change colors etc just for saving the figure.

If you don't buy the above arguments, here is another one: In Jupyter/IPython using the inline backend we can easily display the figures with a different background via

%config InlineBackend.print_figure_kwargs={"facecolor" : "#aaaaaa"}

if you then want to save it you will still want a white background mostly.

So let's not break all the people's notebooks which use a different color than white as background.

It's not clear how

%config InlineBackend.print_figure_kwargs={"facecolor" : "#aaaaaa"}

is different from setting the rcParam (without checking I'd guess that it's redundant with what the rcParam offers; this kind of duplication seriously annoys me :/), so it'd go through the same deprecation.

Sorry, if that wasn't clear. So there is no difference between

%matplotlib inline
%config InlineBackend.print_figure_kwargs={"facecolor" : "#aaaaaa"}
# ... create figure etc.
fig.savefig("myplot.png")

and

%matplotlib inline
plt.rcParams["figure.facecolor"] = "#aaaaaa"
# ... create figure etc.
fig.savefig("myplot.png", facecolor="white")

Both will create grey background figures in the notebook, and save figures with white background.

But this PR intends to remove the facecolor argument. So neither of the above would be possible anymore. In addition, every notebook that relies on the above (e.g. through themes or by manually setting the print_figure_kwargs) would show a deprecation warning in each notebook cell that contains a figure.

Not supporting different "displaying" and "saving" background colors is indeed the intent of this PR, and like any other backcompat break, yes, some people will be annoyed by it.
As noted in the discussion above there are still cases where the intended functionality is broken (#9921) and people who are confused by it (#7619).
Just like @jklymak above (and to quote him), "I'm not sure why folks want to change colors etc just for saving the figure."
Note that the use case in #10023 (comment) can (to a certain extent) be covered by just setting the correct colors when creating the Figure/Axes (obviously, this means having them at display-time too).

@anntzer I think this is a good idea in general. We have too many ways to achieve the same thing. But it seems like it needs more discussion, and probably more use cases carefully laid out. I'm going to close this old PR, and suggest we open an issue. If you feel this is something we should pursue, after a bit more documentation of the plan we could discuss on a call? Of course, feel free to re-open if you strongly feel this is the way to go, but I don't think we have enough consensus yet.

I agree this is basically stuck needing more discussion for now.