You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Also, legends are used in the cycle tests, which includes cycling hatches
for ax.fill() calls. So, that can't be broken or Travis would have noticed
it. So this must be very specific to this plotting function.
On Fri, Sep 23, 2016 at 11:33 AM, Nikita Kniazev [email protected]
wrote:
So it's not about the hatching setting (that's getting put in correctly into the handles), but there's something not right about setting the color used for the hatching; even passing alpha=1.0 (which should be a noop) is enough to get the proper result. This explains why 7bf436c is the offending commit.
Apparently there's some way that the collection accesses/sets the edgecolor for hatching (and not the outline) that patch is missing. I can't seem to find it though.
Eventually _draw_path is called again, but this time the hatch is drawn in transparent black.
So I guess this basically stems from hatching using the edge colour, but not its line width, making it only semi-independent. If we a) went back to using line width for invisible edges, or b) fully separated hatching styling from edge styling, then maybe this would not occur. I'm not sure if there's some way to get a middle ground. The reason that collections work is sort of a happy accident of a few things.
Activity
Kojoley commentedon Sep 23, 2016
2.0.0b3 is fine
http://matplotlib.org/2.0.0b3/examples/api/filled_step.html
WeatherGod commentedon Sep 23, 2016
Also, legends are used in the cycle tests, which includes cycling hatches
for ax.fill() calls. So, that can't be broken or Travis would have noticed
it. So this must be very specific to this plotting function.
On Fri, Sep 23, 2016 at 11:33 AM, Nikita Kniazev [email protected]
wrote:
Kojoley commentedon Sep 23, 2016
Broken by #6904
WeatherGod commentedon Sep 23, 2016
Well, like I said, it does work for ax.fill(), but the bug report is for
filled-step plots, which are different enough, it seems.
On Fri, Sep 23, 2016 at 11:55 AM, Nikita Kniazev [email protected]
wrote:
Kojoley commentedon Sep 23, 2016
9982e40

7bf436c

diff

WeatherGod commentedon Sep 23, 2016
strange... that commit didn't do anything with hatches as far as I can
tell. But it is a major rework of patch objects, so maybe something got
missed?
Also, that doesn't explain how everything works fine for ax.fill() and
legend() (from the cycler tests).
On Fri, Sep 23, 2016 at 12:14 PM, Nikita Kniazev [email protected]
wrote:
WeatherGod commentedon Sep 23, 2016
Waitaminute... could this be a polygon vs. patch issue?
On Fri, Sep 23, 2016 at 12:23 PM, Benjamin Root [email protected]
wrote:
Kojoley commentedon Sep 23, 2016
I am thinking about the same.
afvincent commentedon Oct 2, 2016
Seems to be related: the legend handles of the example contourf_hatching appear to be missing (vs the same example from the 1.5.3 gallery)
dopplershift commentedon Oct 31, 2016
So it's not about the hatching setting (that's getting put in correctly into the handles), but there's something not right about setting the color used for the hatching; even passing
alpha=1.0(which should be a noop) is enough to get the proper result. This explains why 7bf436c is the offending commit.dopplershift commentedon Oct 31, 2016
And setting rcParam
patch.force_edgecolortoTruefixes it as well.dopplershift commentedon Oct 31, 2016
I may be getting out of my depth here. This example reproduces simply:
On matplotlib 1.5.3 this gives:

On 2.x:

Apparently there's some way that the collection accesses/sets the edgecolor for hatching (and not the outline) that patch is missing. I can't seem to find it though.
QuLogic commentedon Nov 1, 2016
Thanks for the example @dopplershift; it made it (relatively) easy to figure out what is going on. I believe the following explains the difference:
For collections:
'none', which after going throughmcolors.to_rgba_arrayis an empty array[].renderer.draw_path_collectionto draw.gc.linewidth = 0.0and b) does not modifygc.colorwhen no edge colours are specified._draw_pathfor each path in the collection, which a) draws the hatching withgc.coloratgc.hatch_linewidthand b) draws no stroke whengc.linewidth == 0.0.The default
gc.coloris opaque black, so the hatch is drawn in black, while the edge is not stroked because of 0 line width.On the other hand, for patches:
'none'again, but is passed throughmcolors.to_rgbainstead and the result is fully transparent black.gc.color; also,gc.linewidthis set to 0 if the colour is transparent._draw_pathis called again, but this time the hatch is drawn in transparent black.So I guess this basically stems from hatching using the edge colour, but not its line width, making it only semi-independent. If we a) went back to using line width for invisible edges, or b) fully separated hatching styling from edge styling, then maybe this would not occur. I'm not sure if there's some way to get a middle ground. The reason that collections work is sort of a happy accident of a few things.
efiring commentedon Nov 1, 2016
Logically, the hatching style parameters should be independent of the edge parameters, so I think that your option b is the one to pursue.
dopplershift commentedon Nov 1, 2016
I agree with @efiring on making hatching its own thing. It wasn't clear to me until I dug in that edge color controls hatching color.
Yet more weirdness in matplotlib that only reveals itself when we fiddle with defaults.
dopplershift commentedon Nov 7, 2016
Fixed by #7415.