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
This is similar to my comments back during the SciPy conference about how
hit-testing is done on the original list of coordinates rather than on the
output list. Other operations like this is also done on the original data
rather than the generated coordinates.
This is a bit trickier, though because the margins are supposed to be about
the datapoints, not the lines. Usually, they are one and the same, but that
is not the case for bezier curves.
I would classify this as "won't fix". Autoscaling is already enough of a mess without trying to take Bezier curves into account. It's not supposed to be perfect, and able to handle every possible situation; it is supposed to provide a decent first-try plot most of the time.
I'm not sure why this was closed; on the current master branch I can reproduce the test case in the original issue, so I don't think this has been fixed yet.
Also worth noting that one needs to manually autoscale the Axes after adding a patch to see the autoscale behaviour, which isn't currently present in the example at the top. Adding axs[1].autoscale() just before plt.show() works, and shows that the control points are still included in the auto scaling.
Activity
WeatherGod commentedon Sep 26, 2016
This is similar to my comments back during the SciPy conference about how
hit-testing is done on the original list of coordinates rather than on the
output list. Other operations like this is also done on the original data
rather than the generated coordinates.
This is a bit trickier, though because the margins are supposed to be about
the datapoints, not the lines. Usually, they are one and the same, but that
is not the case for bezier curves.
On Mon, Sep 26, 2016 at 4:56 PM, Antony Lee notifications@github.com
wrote:
efiring commentedon Nov 14, 2016
I would classify this as "won't fix". Autoscaling is already enough of a mess without trying to take Bezier curves into account. It's not supposed to be perfect, and able to handle every possible situation; it is supposed to provide a decent first-try plot most of the time.
anntzer commentedon Nov 14, 2016
I certainly don't mind milestoning this as 3.0 (as in "far, far future") but I'm don't think the problem is unresolvable.
efiring commentedon Nov 14, 2016
It's not a question of whether it can be solved, but of whether it is worth the effort and the added complexity. We need to set priorities.
dopplershift commentedon Apr 21, 2020
Fixed by #16832.
dstansby commentedon Jan 2, 2021
I'm not sure why this was closed; on the current master branch I can reproduce the test case in the original issue, so I don't think this has been fixed yet.
dstansby commentedon Jan 2, 2021
Also worth noting that one needs to manually autoscale the
Axesafter adding a patch to see the autoscale behaviour, which isn't currently present in the example at the top. Addingaxs[1].autoscale()just beforeplt.show()works, and shows that the control points are still included in the auto scaling.tacaswell commentedon Feb 9, 2023
I think this means it is fixed as adding the auto scaling line gives:
which is scaling to the curve and not to the control points. If
add_patchshould autoscale automatically is a different question!dstansby commentedon Feb 9, 2023
I suspect (but haven't checked) that #19216 fixed this