Is this a bug? add_collection has an explicit autolim parameter, which is False by default.. Ooops sorry, it's True by default, so I'm not sure why this is broken.

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.

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.

Looking through the axes._axes module, the methods which add a collection all call _request_autoscale_view after add_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 to add_collection and make the expected behaviour clear.

Edit: autoscaling is discussed explicitly in this example.

@rcomer "Intentional" or not, the current behavior is not user-friendly and should be improved.

@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.

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.plot([1, 0])
plt.show()

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.

If we simply add a call to _request_autoscale_view within add_collection, we get two test failures:

1. 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.

2. test_arc_in_collection tests consistency between add_collection and add_patch. We can make this one pass by also calling _request_autoscale_view within add_patch, but then we get about a dozen additional test failures...

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.

1. This test was added relatively recently by @oscargus so perhaps he has an opinion on what to do with it.

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...

Running the code in the qt-backend gives a differently looking image. The scatter looks quite similar, but the PathCollection is 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

I think the black edges are just because the test runs in "classic" mode.

I think the black edges are just because the test runs in "classic" mode.

Could be. Documentation may lead one to believe differently:

default: [rcParams["patch.edgecolor"]] (default: 'black')

The return value of get_edgecolor() is array([], shape=(0, 4), dtype=float64) though.

I read up a bit in the source and there is rcParam['patch.force_edgecolor'] which if True, 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.