Skip to content

Hatching in legends is broken #7166

Closed
Closed

Activity

  1. added
    Release criticalFor bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.
    on Sep 23, 2016
  2. added this to the milestone on Sep 23, 2016
  3. WeatherGod commented on Sep 23, 2016

    @WeatherGod
    Member

    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:

    2.0.0b3 is fine
    http://matplotlib.org/2.0.0b3/examples/api/filled_step.html

    —
    You are receiving this because you are subscribed to this thread.
    Reply to this email directly, view it on GitHub
    #7166 (comment),
    or mute the thread
    https://github.com/notifications/unsubscribe-auth/AARy-P0BpG0jA_WlC8ZNoWXqKuq8bZCxks5qs_FcgaJpZM4KElcZ
    .

  4. Kojoley commented on Sep 23, 2016

    @Kojoley
    Member

    Broken by #6904

  5. WeatherGod commented on Sep 23, 2016

    @WeatherGod
    Member

    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:

    Do not we have a test for legends hatching? I thought we have...

    —
    You are receiving this because you commented.
    Reply to this email directly, view it on GitHub
    #7166 (comment),
    or mute the thread
    https://github.com/notifications/unsubscribe-auth/AARy-CFs7NpRdgx1Nxrb00Gb7TejKOqbks5qs_ZtgaJpZM4KElcZ
    .

  6. Kojoley commented on Sep 23, 2016

    @Kojoley
    Member

    9982e40
    filled_step-9982e400c7b21afdebe364d8eb1a8565c5383242

    7bf436c
    filled_step-7bf436c426cfc4f7e2766ff0622ebbdd52d7f6ff

    diff
    filled_step-7bf436c426cfc4f7e2766ff0622ebbdd52d7f6ff-failed-diff

    • legend frame was disabled for bisecting
  7. WeatherGod commented on Sep 23, 2016

    @WeatherGod
    Member

    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:

    9982e40
    9982e40
    [image: filled_step-9982e400c7b21afdebe364d8eb1a8565c5383242]
    https://cloud.githubusercontent.com/assets/2743474/18793048/c7202518-81c1-11e6-9fe7-ec68ca3f6647.png

    7bf436c
    7bf436c
    [image: filled_step-7bf436c426cfc4f7e2766ff0622ebbdd52d7f6ff]
    https://cloud.githubusercontent.com/assets/2743474/18792962/52b7bcf4-81c1-11e6-9e25-cfee8141cbc7.png

    diff
    [image: filled_step-7bf436c426cfc4f7e2766ff0622ebbdd52d7f6ff-failed-diff]
    https://cloud.githubusercontent.com/assets/2743474/18793002/845aa910-81c1-11e6-8124-7178fa39d702.png

    • legend frame was disabled for bisecting

    —
    You are receiving this because you commented.
    Reply to this email directly, view it on GitHub
    #7166 (comment),
    or mute the thread
    https://github.com/notifications/unsubscribe-auth/AARy-K3YMgQk9naOI3YJ0JbJE7plNoKMks5qs_ragaJpZM4KElcZ
    .

  8. WeatherGod commented on Sep 23, 2016

    @WeatherGod
    Member

    Waitaminute... could this be a polygon vs. patch issue?

    On Fri, Sep 23, 2016 at 12:23 PM, Benjamin Root [email protected]
    wrote:

    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:

    9982e40
    9982e40
    [image: filled_step-9982e400c7b21afdebe364d8eb1a8565c5383242]
    https://cloud.githubusercontent.com/assets/2743474/18793048/c7202518-81c1-11e6-9fe7-ec68ca3f6647.png

    7bf436c
    7bf436c
    [image: filled_step-7bf436c426cfc4f7e2766ff0622ebbdd52d7f6ff]
    https://cloud.githubusercontent.com/assets/2743474/18792962/52b7bcf4-81c1-11e6-9e25-cfee8141cbc7.png

    diff
    [image: filled_step-7bf436c426cfc4f7e2766ff0622ebbdd52d7f6ff-failed-diff]
    https://cloud.githubusercontent.com/assets/2743474/18793002/845aa910-81c1-11e6-8124-7178fa39d702.png

    • legend frame was disabled for bisecting

    —
    You are receiving this because you commented.
    Reply to this email directly, view it on GitHub
    #7166 (comment),
    or mute the thread
    https://github.com/notifications/unsubscribe-auth/AARy-K3YMgQk9naOI3YJ0JbJE7plNoKMks5qs_ragaJpZM4KElcZ
    .

  9. Kojoley commented on Sep 23, 2016

    @Kojoley
    Member

    Waitaminute... could this be a polygon vs. patch issue?

    I am thinking about the same.

  10. afvincent commented on Oct 2, 2016

    @afvincent
    Contributor

    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)

  11. dopplershift commented on Oct 31, 2016

    @dopplershift
    Contributor

    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.

  12. dopplershift commented on Oct 31, 2016

    @dopplershift
    Contributor

    And setting rcParam patch.force_edgecolor to True fixes it as well.

  13. dopplershift commented on Oct 31, 2016

    @dopplershift
    Contributor

    I may be getting out of my depth here. This example reproduces simply:

    import matplotlib.pyplot as plt
    import matplotlib.patches as mpatches
    import matplotlib.collections as mcoll
    
    fig, ax = plt.subplots(1, 1)
    rect = mpatches.Rectangle((0, 0), 3, 4, hatch='/')
    ax.add_patch(rect)
    rect2 = mcoll.RegularPolyCollection(4, sizes=[20000], offsets=[(5, 5)],
                                        transOffset=ax.transData, hatch='/')
    ax.add_collection(rect2)
    ax.set_xlim(0, 7)
    ax.set_ylim(0, 9)

    On matplotlib 1.5.3 this gives:
    image

    On 2.x:
    image

    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.

  14. QuLogic commented on Nov 1, 2016

    @QuLogic
    Member

    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:

    1. The default edge colour (without forcing) is 'none', which after going through mcolors.to_rgba_array is an empty array [].
      1. When hatching is enabled, collections use renderer.draw_path_collection to draw.
      2. This function a) will set a default gc.linewidth = 0.0 and b) does not modify gc.color when no edge colours are specified.
      3. It dispatches to _draw_path for each path in the collection, which a) draws the hatching with gc.color at gc.hatch_linewidth and b) draws no stroke when gc.linewidth == 0.0.

    The default gc.color is 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:

    1. The default edge colour is 'none' again, but is passed through mcolors.to_rgba instead and the result is fully transparent black.
    2. When drawing, this edge colour is then translated to gc.color; also, gc.linewidth is set to 0 if the colour is transparent.
    3. 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.

  15. efiring commented on Nov 1, 2016

    @efiring
    Member

    Logically, the hatching style parameters should be independent of the edge parameters, so I think that your option b is the one to pursue.

  16. dopplershift commented on Nov 1, 2016

    @dopplershift
    Contributor

    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.

  17. dopplershift commented on Nov 7, 2016

    @dopplershift
    Contributor

    Fixed by #7415.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Release criticalFor bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions