Also please note that of course I don't think people should save at 30dpi. The point here is that even at 300 dpi, if someone tries to imshow 10k x 10k matrix they will get aliasing and we really should anti-alias by default unless they explicitly tell us not to (antialiased=False)

That is really nice.
On the other hand, speed-wise it's a bit of a disaster -- for a 2000x2000 image (the case initially posted on gitter, rendering takes dozens of seconds (whereas it's basically instantaneous without antialiasing), so I still think a simple boxcar would be useful (if it indeed delivers reasonable performance). Also, thinking again about @tacaswell's comments on gitter, there are indeed cases where other aggregations than mean (or weighted mean, which is basically what this is doing) are useful; for example, the data I'm visualizing is basically a large 0-1 matrix (hence the example) where I want mostly to see the 1's (which are actually rare), so e.g. taking the max() in each pixel would make sense (for my data).
Again, this is to suggest further improvements, not to take anything away from the PR here which is 👍👍

The agg filters are written in c and as far as I can tell are just simple convolutions. So it’s not clear if a different shaped filter would be more efficient. 2d convolutions are slow. We could try w scipy.conv2d which should also be pretty optimized. I think the algorithm is NxMxrxr where r is the filter radius.

My guess from some quick playing around w/ scipy.signal.convolve2d is that the agg filters are relatively large (i.e. a few times r) and hence the convolution is slow. It'll take some poking around to see if there is a way to control the size of the filter. Certainly a smaller np.ones((r*2, r*2))/(4*r**2) would be "good enough" and probably a lot more compact..

I am not sure it is actually implemented as a convolution, I think it is

for pixel in output_image:
    out[pixel] = apply_kernel(input_image, mapped_to_input_space(pixel), kernel_generator(pixel))

where the kernel_generator deals with the sub-pixel offset between the two grids. The upside is that you only evaluate the convolution where you actually need it (because the output domain demands it) but the downside is you generate the kernel N times, hence my suggestion to use a simpler kernel.

@anntzer this doesn't do what you are after, which would be to essentially add more anti-aliasing filters to the agg code. I don't think that would be outrageously hard, but this PR is much more modest in what it is trying to do...

Can you also add the timings with antialiasing disabled?
I guess some example images with >2x oversampling to show that antialiasing is not needed anymore in that case would be nice too.

@anntzer updated above:

filt nearest dpi 210 time 0.241
filt nearest dpi 95 time 0.382

So less than 2x slowdown. Given the "esthetic" quality improvement, this is really good.
Perhaps add an rcparam and a whatsnew suggesting to turn this on in the matplotlibrc at least? (@tacaswell would you be willing to even consider making this on by default?)

This PR proposes to make it on by default.

I'm happy with that, but I guess some will complain :)

I'm happy with that, but I guess some will complain :)

Maybe, but I don't think they should - the [sampling theorem]((https://en.wikipedia.org/wiki/Nyquist–Shannon_sampling_theorem) is pretty inescapable. I don't think we should show aliased images to our users unless they specifically ask for them.

I actually think we should just leave Gaussian on by default: even when upsampling it helps. This image is upsampled by 2.05:

Though I guess if we upsample by an integer we could turn it off: note the thin colours at the corners are washed out w/ the Gaussian blur...

OK, the problem with all this is that manually zooming doesn't re-call _make_image, so you as you start upsampling, it doesn't change the filter... That seems a pretty huge drawback. I guess I don't quite understand when the image gets rendered to canvas where that happens if not _make_image... Does this all have to happen lower down at the draw stage?

When upsampling by a large amount, quite often (for some definition of "quite often") one does (I do, at least) expect to see sharp pixel boundaries and the blurring out by the filter is just annoying. Obviously there's no sharp transition between "we need an antialiasing filter" and "we don't need one", but we need to set it somewhere (if we agree we don't want it when the pixels are large) and putting it where the sampling theorem says to put it sounds like a reasonable default.

For sure when zooming you want the blur to be un-noticable. OTOH, we use the transform stack to keep track of what part of the image will be drawn makes it challenging to see how zoomed in we are, so its hard to know how many data pixels are geing mapped to how many canvas pixels a-priori... (well or my ignorance of how to get such things out of an arbitrary transform needs to be overcome).

New version works w/ zooming. I found it easiest to drag-resize this code to see the changes...

import matplotlib.pyplot as plt
import numpy as np
import scipy.signal as signal
import timeit

a = plt.imread('rings_sm_orig.gif')
print(np.shape(a))

for dpi in [200]:
    fig, axs = plt.subplots(1, 2, figsize=(4.1, 2.1), num=1, sharex=True, sharey=True)
    ax = axs[0]
    ax.imshow(a, cmap='gray', antialiased=True)
    ax.set_position([0, 0, 0.5, 1])
    if 1:
        ax = axs[1]
        ax.imshow(a, cmap='gray', antialiased=False)
        ax.set_position([0.5, 0, 0.5, 1])
        ax.axis('off')
        ax.text(100, 190, dpi, fontsize=40)

plt.show()

Before working on tests and docs I'd like some consensus that this is the way to go....

I'm definitely +1 on providing this functionality, undecided but leaning towards +1 on having this on by default.

I actually do not understand the test failure. Its saying "antialiased" is not a valid value for "interpolation", but all the other tests work fine. And I can't reproduce locally, ie. the failing test runs fine locally.