GeezerVison

If code coverage passes, that should be at least some indicator that we didn't drop anything relevant.

OK, I've also removed hist2d (because it is just a pcolormesh), and markevery (because it's just a line + scatter).

Why prefer png over svg/pdf?

A spot check of sizes looks like the pdf's are the smallest (presumably because they are compressed by default) and svgs are the most "text like" so should play the best with git. I was going to assert that the vector layouts would be insensative to freetype but began to doubt that as I was typing (I am not sure if we rely on freetype to do any placement even in those cases).

The biggest upside I see of png is that it is no optional test-deps to run.

A spot check of sizes looks like the pdf's are the smallest (presumably because they are compressed by default) and svgs are the most "text like" so should play the best with git. I was going to assert that the vector layouts would be insensative to freetype but began to doubt that as I was typing (I am not sure if we rely on freetype to do any placement even in those cases).

Unfortunately not, or this wouldn't have come up in #29816. Admittedly, I don't think it's all of them, though.

The biggest upside I see of png is that it is no optional test-deps to run.

This is definitely the main reason, but I have no issues with changing to SVG/PDF if we think that's okay.

I also suspect (but have not measured) that the png tests are faster as we don't effectively render 2x and require a sub-process to be running.

Despite asking the question, I'm coming around to png being the right choice.

Should we change the default extensions of check_figures_equal to only png? Figure comparisons often create the same artists but with different code paths. Therefore rendering to any output should be sufficient. I believe it's quite the exception that we need more than one output.

Good idea, but it is in the public API right now. I seem to recall us saying that matplotlib.testing may not have the same API guarantees, but I can't find where that is.

I'd be so bold and just change it, documenting it in an API change note.

It should be "what users want" 99% of the time, and there's no simple deprecation/migration route.

OK, I've changed the default and removed the extraneous extensions arguments.

Not a 100% exact comparison but this test run is 9630 tests in 12:37min, where a test run on another recent PR is 9845 tests in 13:54min. So a rough estimate is that we have shaved off 200 tests and 1:20min test runtime. That's a significant improvement 🎉.

This and #29816 will need to be backported to 3.10.x.

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

git checkout v3.10.x
git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

git cherry-pick -x -m1 662239c31e3a080e9bcbe69cd51452a9c0506d97

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

git commit -am 'Backport PR #29827: TST: Remove unnecessary test images'

4. Push to a named branch:

git push YOURFORK v3.10.x:auto-backport-of-pr-29827-on-v3.10.x

5. Create a PR against branch v3.10.x, I would have named this PR:

"Backport PR #29827 on branch v3.10.x (TST: Remove unnecessary test images)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the Still Needs Manual Backport label once the PR gets merged.

If these instructions are inaccurate, feel free to suggest an improvement.