Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
Separates edgecolor from hatchcolor#28104
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
There are two tests that are currently failing and need a rewrite.
|
Pinging@story645 for review |
Sorry for delay, will try to review but please add some tests. |
Also this should probably go in before#27937 b/c I agree that it'll probably clean that one up. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I think this might need some discussion on how to manage since the changes dive pretty deep into the internals, but definitely add some tests cause that could help you debug the segfault.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
For this change we need to make sure both:
This will also need a lot of documentation (both notifying third-party backends the expected API is changing) and announcing the new feature to users (with lots of examples). |
Uh oh!
There was an error while loading.Please reload this page.
Could I also go ahead with rewriting the two tests that are failing? |
story645 commentedAug 30, 2024 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
It shouldn't be failing. This is what@tacaswell was talking about that you want to make sure the code is backwards compatible. The test contour_hatch also seems like it should still pass, is there a reason it shouldn't? |
The initial comment explains the reason |
Sorry, I updated while you posted. For the tests:
I think the user specified alpha should also be propagated to hatchcolors, w/ the same priority rules as color and edgecolor, which should then make the test pass.
|
It may be simpler to work out what the non-vectorized version of this API looks like (so do just the classes in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
couple of small comments but I'm really impressed w/ the work you've done here and how far this PR has come. 😄
Uh oh!
There was an error while loading.Please reload this page.
if self._edgecolor[3] == 0: # fully transparent | ||
return colors.to_rgba(mpl.rcParams['patch.edgecolor']) | ||
return self.get_edgecolor() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
so just checking that this will get followed up and just used get_edgecolor? cause like I mentioned, I'm uncomfortable with using transparent edge as the test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
discussed this on the call today and is this being done to maintain backward compatibility if someone sets edgecolor toNone
and doesn't definehatchcolor
orhatch.color
to ensure that something gets drawn?
my thinking is that that should return a warning "Setting a hatch but hatch and edgecolor are none" but we shouldn't special case a fallback (that also may not work if patch.edgecolor is "none")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
is this being done to maintain backward compatibility if someone sets edgecolor to
None
and doesn't definehatchcolor
orhatch.color
to ensure that something gets drawn?
Yes. This is for the final fallback where edgecolor is set to 'none', and hatchcolor is not set in which casepatch.edgecolor
rcParam is used and this condition is there to check whetheredgecolor
is None. Removing this condition causestest_artist::test_hatching
to fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Ok, so we should discuss if this behavior should be deprecated (b/c it's an iffy fallback to rely on facecolor.rcparam being set to not None) now that we allow an explicit hatchcolor, but I think it's okay to push that to a follow up to this PR.
Is part of the problem here eager resolution of edgeolor so you can't check that edgecolor is None (hasn't been set)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Yes, ashatchcolor
must depend on the currentedgecolor
now, we are essentially special casing for when thehatchcolor
came through asblack
from the rcParam in the previous implementation. I believe we can't really check if the edgecolor is None in a better place
I am for hatching with the rcParam when nohatchcolor
is specified as it not only maintains backward compatibility but seems more natural for a user to not care about thehatchcolor
, but the next best thing would be to raise a warning as mentioned above
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I'm gonna move the discussion of deprecating to a new issue, but my concern is that the fallback on edgecolor='None' means:
- if edgecolor='None' you'll backfill with 'patch.edgecolor' but that may also be None and this all happens silently
- edgecolor=('green', 0) will also trigger this path and the person may have wanted the 'green' and were gonna up the alpha
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
slight wording nits but otherwise I think this is good to go and a feature I wanted a few weeks back
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
if self._edgecolor[3] == 0: # fully transparent | ||
return colors.to_rgba(mpl.rcParams['patch.edgecolor']) | ||
return self.get_edgecolor() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I'm gonna move the discussion of deprecating to a new issue, but my concern is that the fallback on edgecolor='None' means:
- if edgecolor='None' you'll backfill with 'patch.edgecolor' but that may also be None and this all happens silently
- edgecolor=('green', 0) will also trigger this path and the person may have wanted the 'green' and were gonna up the alpha
Uh oh!
There was an error while loading.Please reload this page.
c11175d
intomatplotlib:mainUh oh!
There was an error while loading.Please reload this page.
Thanks@Impaler343 for going with us through the lengthy discussion and design process. |
Uh oh!
There was an error while loading.Please reload this page.
PR summary
Taking after@Vashesh08 's PR#26993
Shouldclose#26074 and#7059
Implemented the fallback logic that@story645 mentioned in thiscomment
Cherry picked some initial commits from the Issue26074 branch written by Vashesh
Modified the hatchcolor setting to way similar to edgecolor setting.
PR checklist