Repository navigation
[Bug]: Missing axes limits auto-scaling support for LineCollection #29219
Description
Bug summary
Matplotlib is missing auto-scale support for LineCollection.
Related issues:
- [Bug]:
add_collection3ddoes not update view limits #23317 - FIX: Autoscale support in add_collection3d for Line3DCollection and Poly3DCollection #28403
Code for reproduction
from matplotlib import pyplot as plt
from matplotlib.collections import LineCollection
lc = LineCollection([[(x, x ** 2) for x in range(5)]])
ax = plt.gca()
ax.add_collection(lc)
# ax.autoscale() # need to manually call this
plt.show()Actual outcome
Expected outcome
Additional information
No response
Operating system
macOS 14.6.1
Matplotlib Version
3.9.3
Matplotlib Backend
macosx
Python version
3.12.7
Jupyter version
7.2.2
Installation
pip
Activity
jklymak commentedon Dec 4, 2024
Is this a bug?. Ooops sorry, it's True by default, so I'm not sure why this is broken.add_collectionhas an explicit autolim parameter, which is False by default.li-ruihao commentedon Dec 5, 2024
Hello, would this be a good first issue? This is my first time contributing to Matplotlib, can I take a look at this? I know issues will not be assigned and PRs are considered on a first come first serve basis, but I need to work on an issue for a school project so I am wondering how much learning curve this requires.
QuLogic commentedon Dec 5, 2024
There is already a PR open to fix this, linked above. I have not looked at it myself to see what state it is in.
rcomer commentedon Dec 6, 2024
Looking through the
axes._axesmodule, the methods which add a collection all call_request_autoscale_viewafteradd_collection. So I think the autolim parameter works to update the data limits, but the axises still need to be told those limits have changed. This would appear to suggest that the current behaviour is intentional but if nothing else we should add a docstring toadd_collectionand make the expected behaviour clear.Edit: autoscaling is discussed explicitly in this example.
carlosgmartin commentedon Dec 6, 2024
@rcomer "Intentional" or not, the current behavior is not user-friendly and should be improved.
rcomer commentedon Dec 7, 2024
@carlosgmartin I agree that the current behaviour is unlikely to be what anyone wants. Indeed, if you plot something else that has autoscaling after adding the collection then it autoscales both. Whether something gets autoscaled should not depend on whether you add something after.
However, it does appear to have been deliberately written this way and I think we should try to understand why it was written this way. Understanding that can help us scope what kind of task it would be to change it.
rcomer commentedon Dec 7, 2024
If we simply add a call to
_request_autoscale_viewwithinadd_collection, we get two test failures:test_path_collection where the current image is this:
but the new behaviour gives this, because the y-axis is now much taller
This test was added relatively recently by @oscargus so perhaps he has an opinion on what to do with it.
test_arc_in_collection tests consistency between
add_collectionandadd_patch. We can make this one pass by also calling_request_autoscale_viewwithinadd_patch, but then we get about a dozen additional test failures...timhoffm commentedon Dec 7, 2024
We have a lazy limit update mechanism, but I don’t know the details and which part of the code are responsible for which aspects of that. I believe we have to clarify this to find out, what the right solution is. It might also be that this is currently not handled consistently across functions.
oscargus commentedon Dec 7, 2024
The purpose of the test was to get coverage, so the test image is just randomly generated. My impression is though that everything is shown in the test image so the compression is not caused by things that are not drawn. I guess seeing the axis here would be interesting to understand what happens. (As the data is randomly generated, I guess I just tried things until I got a reasonable looking image.)
Note that this test was for a previously untested part of the ps-backend, so it may very well be that there is a bug in the ps-backend and that one should run the same code with other backends so see if that is the case...
oscargus commentedon Dec 7, 2024
Running the code in the qt-backend gives a differently looking image. The scatter looks quite similar, but the
PathCollectionis rendered differently, larger size and no black edges.Saving it as PDF leads to a similar image as the test image, but no black edges.
(both are screen shots)
So something is quite strange here...
Edit: this is on 3.8.3
rcomer commentedon Dec 7, 2024
I think the black edges are just because the test runs in "classic" mode.
oscargus commentedon Dec 7, 2024
Could be. Documentation may lead one to believe differently:
The return value of
get_edgecolor()isarray([], shape=(0, 4), dtype=float64)though.oscargus commentedon Dec 7, 2024
I read up a bit in the source and there is
rcParam['patch.force_edgecolor']which ifTrue, the statement in the documentation is correct, otherwise the edge color is set to'none'I can sort out a correction to the documentation if nothing else.
QuLogic commentedon Aug 2, 2025
Seems to be fixed by #29958.