Repository navigation
Linestyle pattern depends on current style, not style set at creation #6592
Description
This is on 2.x (both the beta and current git HEAD) and confused me for the longest time:
from matplotlib import style
import matplotlib.pyplot as plt
def make_fig():
fig = plt.figure()
ax = fig.add_subplot(1, 1, 1)
ax.plot([1, 2, 3], linestyle='dashed')
ax.grid(True)
return fig
with style.context('classic'):
fig = make_fig()
fig.savefig('test1.png')
fig.savefig('test2.png')
fig = make_fig()
fig.savefig('test3.png')So the first save_fig() gives the classic style as expected:
And the last save_fig() gives the new defaults:
But for some reason the 2nd savefig(), where the figure is created with the classic style, but is written outside the context manager gives a figure that looks like classic, except the dash pattern different:
This seriously confused me for the afternoon--it wreaks havoc with my tests where I'm now setting the stylesheet to classic inside the test. When pytest-mpl saves the test outside the context manager (and outside my test function) I get some weird abomination.
Activity
efiring commentedon Jun 16, 2016
When
savefigis executed, it draws the figure. If this is outside the context manager, then all operations that are done at drawing time will be without that context. Anything that was established before drawing time will be with the context. I don't think there is any way to get around this--it's fundamental to the way mpl and context managers work. Some things are figured out a drawing time, others at object creation time. The particular case here where the dash pattern matches neither style is a surprise, I agree.WeatherGod commentedon Jun 16, 2016
There are a bunch of oddities here. Notice that the font size seems
smaller, and it seems to me that the line width is slightly smaller, too? I
wonder if the dpi or the figure size is getting messed up, too? If so,
could this explain some of our intermittent test failures where the result
image has the wrong size?
On Thu, Jun 16, 2016 at 1:53 AM, Eric Firing [email protected]
wrote:
tacaswell commentedon Jun 16, 2016
Any of the draw-time consultations of checking for the internal classic style need to turn into caching that on the artists 😞
dopplershift commentedon Jun 16, 2016
To say it's surprising is an understatement. At a bare minimum, this needs to be in bold print with the docs for
style.context.I recognize how much of a pain in the ass it would be to fix this completely--but I feel confident in saying that having these 3 possibilities is a terrible user experience (though hopefully not frequently encountered). If we agree that in principle that
savefig()should produce the expect results when called outside the context manager, then at least we know what to do when issues like this crop up.efiring commentedon Jun 16, 2016
On 2016/06/16 5:20 AM, Ryan May wrote:
If I understand you correctly, then I don't agree with this in
principle. From creating the Figure to the last savefig, figure
generation has to be either in a context, or outside. It doesn't make
sense to be half in and half out. That's the point of a context
manager. When you leave the context, you've finished with it and reset
whatever state setting was done. Maybe the problem is that the context
manager is not the appropriate tool here; or it should be a Figure
generation context, ensuring the Figure is closed upon exit.
dopplershift commentedon Jun 16, 2016
Well, I would have expected the following to work
But I now see the semantics of it (especially with property cycles) are a bit complicated. So in lieu of that, is there any mechanism that gives something like:
What I'm running up against is the problem that styles are a global state, and I really don't want to be mucking with global state in tests.
dopplershift commentedon Jun 16, 2016
Oh, and I just found this in the stylesheet docs:
So whoever wrote this intended it to work as I expected....
efiring commentedon Jun 16, 2016
I agree; I have never liked rcParams, with its massive global state. It is particularly dangerous as a mechanism for controlling local state, flipping settings back and forth. I suspect we can figure out better ways of handling this, but not as modifications to 2.0.
dopplershift commentedon Jun 16, 2016
Well, we have a problem for 2.0 since the stylesheets will IMO see a lot more use as people fall back to 'classic' for cases like this. The fact that our own docs are wrong on this really bothers me.
tacaswell commentedon Jun 16, 2016
@dopplershift it definitely should work as you expected.
efiring commentedon Jun 16, 2016
I'm probably over-reacting because of my dislike for rcParams; I will defer to @tacaswell's judgment. It seems like the question is whether all factors influenced by rcParams can be frozen based on the rcParams values at the time of artist creation, and the answer is "no", because layout is only finalized when the figure is drawn, so it has to depend on
figure.dpiat that point. Properties like color are easy to handle; anything involving layout is not. Even though they involve size, I think the dash patterns should be in the former (easy) category, and if they are not, that is a bug. (I have a vague sense that we have dpi dependencies where we shouldn't--things are getting converted back and forth between dots and physical units unnecessarily.)tacaswell commentedon Jul 11, 2016
with #6710
You get
I do not think you can get around the remaining difference between test1 and test2 because the default savefig dpi should be looked up at save time, not at figure creation time.
FIX: do dash scaling early
FIX: do dash scaling early
FIX: do dash scaling early
FIX: do dash scaling early