-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
[MNT]: Confusing edgecolor behavior for Patch and Collection #29261
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
Comments
Your analysis and proposal look fine to me. |
Hi @timhoffm , While testing the behavior of If facecolor is "none", Patch and Collection take rcParams["patch.edgecolor"] as edgecolor. What I Did:
Is this the expected behavior? Or did I miss something in my setup? Further, I’d like to contribute to this issue. |
I can’t really tell on the expectation. I’ve just tried to deduce the current behavior, but I may have done a mistake. I don’t have time to dig into this deeper right now. Anyway the way forward on this issue is
|
Okay, I am working on it, If I encounter any specific questions or uncertainties during this process, I’ll reach out to you. |
Hi @timhoffm, If color is explicitly provided, edgecolor uses that color directly.
if we want change default the problem occurs when |
Hi @timhoffm, just checking in on my previous comment. Let me know if you have any thoughts on it or if I should clarify anything. Thanks! |
@timhoffm can you please take a look at the above comments. |
Sorry, I don't have enough quiet time right now to really think this through. It's tying a knot in my brain when I try to have a quick look. From what it seems, |
Hi @timhoffm currently, if |
I believe the best way forward is to codify the current (intended) behavior in tests. Then refactor and make sure the resulting edgecolor stays the same. |
@timhoffm I have made the PR, containing tests cases for |
As noted in #29690, it only codifies current behaviour in tests, and does not fully fix this issue. |
Uh oh!
There was an error while loading. Please reload this page.
Noted while reviewing documentation on the current behavoir in #29252.
Summary
Patches and Collections do not draw edges by default. This was introduced in #5596 for matplotlib 2.0. It seems that this was first achieved by a linewidth 0, but it this was changed to using an edgecolor of "none" while maintaining a finite linewidth.
As a consequence
rcParams["patch.edgecolor"]
does not have an effect by default. There are, however two cases whenrcParams["patch.edgecolor"]
becomes relevant:rcParams["patch.edgecolor"]
as edgecolor.I assume, this is done to prevent the artist being completely invisible (no facecolor and no edgecolor).
rcParams["patch.force_edgecolor"]
is set to true,rcParams["patch.edgecolor"]
is used instead of "none" as theThis is overall very confusing.
Ping @efiring, who introduced
rcParams["patch.force_edgecolor"]
in #6904. Can you comment on the background and whether the proposal below is a reasonable alternative?Proposed fix
Can we switch to the following logic:
patch.edgecolor
is generally used as edgecolor and now defaults to "none" (to achieve the same behavior as before). To handle case 1. (prevent invisible artists) introduce a newrcParams["patch.edgecolor_fallback"]
that has a special color only for that case.Needed changes to default rcParams
matplotlibrc before:
matplotlibrc after
Needed changes to styles
Existing styles would migrate
patch.force_edgecolor
was False:from:
patch.force_edgecolor
was True:from:
Transition path
patch.force_edgecolor
gets deprecated and raises a warning when used on rcParams.patch.edgecolor
orpatch.force_edgecolor
do not have to do anything.patch.edgecolor
but notpatch.force_edgecolor
are a very edge case. They either have overlooked that the defaultforce_edgecolor=False
makes the setting ineffective, or they have intentionally only configured the somewhat arcane edge color fallback for non-filled artists. In the former case, they get "auto-fixed" through the new behavior. I'd argue that we can affort to not runtime-warn on the latter case (but if really wanted, one could add a check at least for loading stylesheets).The text was updated successfully, but these errors were encountered: