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
{{ message }}
Repository navigation
[Bug]: Hatch linewidths cannot be modified in an rcParam context #21108
The only way (that I am aware of) to control the linewidth of hatches is through an rc parameter. But temporarily modifying the parameter with plt.rc_context has not effect.
So I am hoping that there is a small bug with hatch.linewidth where it is getting read from the rcparams at the wrong time. A proper hatching API has been on the agenda for years now with no one stepping up to take it on so I don't think that should stand in the way of sanding down rough edges where possible.
Reacted by Jody Klymak, Tim Hoffmann, Neil Gurnani and Dhinakaran K
Indeed, hatch.linewidth is only used within backend code, which makes it clear that it's evaluated at draw time and thus the context manager cannot have any effect. In contrast, Patch and Collection store a self._hatch_color during creation.
Marking as good first issue, because the implementation of hatch.linewidth handling must only be adapted to be analogous to hatch.color.
However I wonder if we have somewhere we could codify draw parameter resolution. For all the people who want to use a context manager and have properties set at creation, we have the equally reasonable request that rcParams are checked at drawtime so folks can style after they have created a bunch of artists. I think most of the library is consistent with "defaults resolved at creation" but I'm not sure we document this.
See also #12967, #11710: I think rcparams should be resolved at artist creation time, mostly because proper delayed resolution would be rather hard to implement given the current architecture of things.
Reacted by Jody Klymak, Tim Hoffmann and Neil Gurnani
@Fefedu75 Yes, this issue is still unresolved. The work that needs to be done is to convert the patch in the issue above into a PR, add tests, and add documentation of the new feature.
Thanks for checking this @rishavganguly007! However, I think for the first (red) subplot the hatches should be thinner. So something else seems to be going wrong in your example 🤔
@rishavganguly007 I think if you put the three calls in separate cells in your notebook, you might reproduce the problem in the OP. I think the call to rc on the penultimate line affects everything that is drawn for that cell.
I think if you put the three calls in separate cells in your notebook, you might reproduce the problem in the OP.
Indeed @rcomer, separating 3 calls in 3 different cells reproduces the OP's issue. Thanks.
However, a question arises here, so the call to rc on the penultimate line - why It affected the other two calls that were placed above it? Is it something related to Google Colab, or is this how it is?, or it's a bug?
Coming to the issue,
What I understood reading from comments, can you please confirm that is this what is expected from this issue?.
@Fefedu75 Yes, this issue is still unresolved. The work that needs to be done is to convert the patch in the issue above into a PR, add tests, and add documentation of the new feature.
so the call to rc on the penultimate line - why It affected the other two calls that were placed above it? Is it something related to Google Colab, or is this how it is?, or it's a bug?
It’s not specific to Google Colab: I found the same thing by running the example as a script locally: if I put plt.show() once at the end of the script, then my three figures pop up with thick hatches an all of them. If instead I add plt.show() after each call to bar, then I get the figures one at a time, and they look like those in the OP. I think that the rcParam affects what happens at draw time, (i.e. when you call show or savefig in a script) rather than affecting attributes on the Figure objects. In a notebook, draw is called implicitly at the end of a cell.
What I understood reading from comments, can you please confirm that is this what is expected from this issue?.
@Fefedu75 Yes, this issue is still unresolved. The work that needs to be done is to convert the patch in the issue above into a PR, add tests, and add documentation of the new feature.
Yes I think so. Someone made a start at #21325, but it seems that got caught up in some gnarly git history problems. So it may well be easiest to start again.
You've discovered a different manifestation of the bug as reported in the issue. The hatch linewidths are determined by the state of the rcParams at the time the figure is drawn not at the time the artists are created (as is the case for most other visual attributes in matplotlib). That's why the context manager doesn't work (the figure is drawn after the parameters revert back to their original values) and why changing the global settings in a cell retroactively modifies figures (because the inline backend collects all open figures and draws them after executing the cell).
I see that the PR above (#25367) has been closed due to stalling on some test failures. Should it be reopened, so I can fix the failures, or should I start from scratch on a completely new PR?
Adding tests (and more annoyingly, backcompat knobs) is left as an exercise to the reader.
I've read through this diff and applied the changes described. How do I implement tests for this? Also, what exactly are backcompat hooks, and how would I implement them?
Adding tests (and more annoyingly, backcompat knobs) is left as an exercise to the reader.
I've read through this diff and applied the changes described. How do I implement tests for this? Also, what exactly are backcompat hooks, and how would I implement them?
Activity
story645 commentedon Sep 17, 2021
totally agree that there should be a
HatchStyleobject that holds theany other attributes of the hatch...
mwaskom commentedon Sep 17, 2021
I guess this is not the first time I've noticed this :)
jklymak commentedon Sep 17, 2021
... someone who uses hatches has to implement the new API, but I think it would be a welcome addition....
mwaskom commentedon Sep 17, 2021
I agree but this apparently does work for
hatch.color:So I am hoping that there is a small bug with
hatch.linewidthwhere it is getting read from the rcparams at the wrong time. A proper hatching API has been on the agenda for years now with no one stepping up to take it on so I don't think that should stand in the way of sanding down rough edges where possible.timhoffm commentedon Sep 17, 2021
Indeed,
hatch.linewidthis only used within backend code, which makes it clear that it's evaluated at draw time and thus the context manager cannot have any effect. In contrast,PatchandCollectionstore aself._hatch_colorduring creation.Marking as good first issue, because the implementation of
hatch.linewidthhandling must only be adapted to be analogous tohatch.color.jklymak commentedon Sep 18, 2021
Seems reasonable.
However I wonder if we have somewhere we could codify draw parameter resolution. For all the people who want to use a context manager and have properties set at creation, we have the equally reasonable request that rcParams are checked at drawtime so folks can style after they have created a bunch of artists. I think most of the library is consistent with "defaults resolved at creation" but I'm not sure we document this.
anntzer commentedon Sep 18, 2021
See also #12967, #11710: I think rcparams should be resolved at artist creation time, mostly because proper delayed resolution would be rather hard to implement given the current architecture of things.
anntzer commentedon Sep 18, 2021
Also, I think the patch to resolve hatch linewidth early should basically be
(the main complication is the the vector backends hatch emitters needed to be updated as well.)
Adding tests (and more annoyingly, backcompat knobs) is left as an exercise to the reader.
Fefedu75 commentedon Sep 29, 2021
Hello ! We are students from an Ingenier school and we are specializing in open source software. We hoped help you, is this problem still unsolved ?
tacaswell commentedon Sep 29, 2021
@Fefedu75 Yes, this issue is still unresolved. The work that needs to be done is to convert the patch in the issue above into a PR, add tests, and add documentation of the new feature.
9 remaining items
rishavganguly007 commentedon Feb 26, 2023
Hello,
I tried to reproduce the code mentioned in the ticket
However I am getting a different result:
Unlike the original posted images, I'm getting equal linewidths for all the 3 hatches
Here is my collab document : https://colab.research.google.com/drive/14WAgV-hVgmjIaBhqw6UQI1wBMjO5FXrq#scrollTo=846DkmimmGaL
I have tested in:
Name: matplotlib
Version: 3.5.3
So what I wanted to know is the issue fixed with the new versions?
Thanks
rcomer commentedon Feb 26, 2023
Thanks for checking this @rishavganguly007! However, I think for the first (red) subplot the hatches should be thinner. So something else seems to be going wrong in your example 🤔
rcomer commentedon Feb 26, 2023
@rishavganguly007 I think if you put the three calls in separate cells in your notebook, you might reproduce the problem in the OP. I think the call to
rcon the penultimate line affects everything that is drawn for that cell.rishavganguly007 commentedon Feb 26, 2023
Indeed @rcomer, separating 3 calls in 3 different cells reproduces the OP's issue. Thanks.
However, a question arises here, so the call to rc on the penultimate line - why It affected the other two calls that were placed above it? Is it something related to Google Colab, or is this how it is?, or it's a bug?
Coming to the issue,
What I understood reading from comments, can you please confirm that is this what is expected from this issue?.
Thanks
rcomer commentedon Feb 26, 2023
It’s not specific to Google Colab: I found the same thing by running the example as a script locally: if I put
plt.show()once at the end of the script, then my three figures pop up with thick hatches an all of them. If instead I addplt.show()after each call tobar, then I get the figures one at a time, and they look like those in the OP. I think that the rcParam affects what happens at draw time, (i.e. when you callshoworsavefigin a script) rather than affecting attributes on theFigureobjects. In a notebook, draw is called implicitly at the end of a cell.Yes I think so. Someone made a start at #21325, but it seems that got caught up in some gnarly git history problems. So it may well be easiest to start again.
mwaskom commentedon Feb 26, 2023
You've discovered a different manifestation of the bug as reported in the issue. The hatch linewidths are determined by the state of the rcParams at the time the figure is drawn not at the time the artists are created (as is the case for most other visual attributes in matplotlib). That's why the context manager doesn't work (the figure is drawn after the parameters revert back to their original values) and why changing the global settings in a cell retroactively modifies figures (because the inline backend collects all open figures and draws them after executing the cell).
kidkoder432 commentedon Oct 6, 2023
I see that the PR above (#25367) has been closed due to stalling on some test failures. Should it be reopened, so I can fix the failures, or should I start from scratch on a completely new PR?
oscargus commentedon Oct 6, 2023
The best thing is to start a new PR which uses the commits from the old one.
kidkoder432 commentedon Oct 6, 2023
kidkoder432 commentedon Oct 7, 2023
I've read through this diff and applied the changes described. How do I implement tests for this? Also, what exactly are backcompat hooks, and how would I implement them?
kidkoder432 commentedon Oct 7, 2023
@tacaswell @anntzer
rcomer commentedon Oct 8, 2023
backcompat knobs: if we make a change that could alter the outcome of a user’s existing code in some way, then we must not do that without warning. Guidelines for this are at https://matplotlib.org/stable/devel/contribute.html#api-changes
We have guidance on writing tests here: https://matplotlib.org/stable/devel/testing.html