GeezerVison

The original issue with current style looks like this:

and now looks smoother:

and the animation is smoother:

What is between us and marking this ready for review?

This certainly works well for circles, which do not have special directional edges. We should check how this looks for squares: Do subpixel interpolated edges give the impression of “in between position” or just “blurry”?
Same question for line-like markers like “x” and “+”.
Maybe whether to interpolate and the number of interpolation steps needs to be chosen depending on the marker type.

What is between us and marking this ready for review?

The main issue is this one. It looks like if we disable snapping on the cached markers, we end up with ~450 test failures, though they are mostly due to ticks being 1 pixel shorter.

Can we special-case TICKDOWN / TICKUP markers so that they keep their old behavior?

IMHO mid-term, the implementation of ticks via Line2D with specific markers should become an implementation detail. But tick1line and similar are currently exposed, so that we don't want to wait for the necessary changes there to add subpixel snapping.

In mplcairo ticks are not drawn with stamping at all but by drawing them one at a time, which IIRC is indeed needed to make them sharp and not blurry. Actually this is not an explicit switch but just the consequence of other choices: the size of the pattern cache (which is pre-populated prior to sampling) is normally between 9**2 (where 9 is the inverse of the default path.simplify_threshold) and an arbitrary upper bound of of 16**2 (i.e. between 9 and 16 subpixels in both x and y), and if the total number of markers to be drawn is less than the size of the cache then I don't use the cache at all (as we don't expect it to help).
So for a single-marker draw (e.g. a tick) we just bypass the cache.
(Maybe if the design was to lazily populate the cache as entries are used then I would have added an explicit check instead to bypass the cache for single-marker draws.)

I've rebased and added the image changes for people to look at. I don't quite think we should keep them all, but I haven't looked into any additional special-casing besides the pixel marker (which needs to be optimized, probably.)

There also seems to be some check_figures_equal tests that fail, which I'll need to investigate further.

and if the total number of markers to be drawn is less than the size of the cache then I don't use the cache at all (as we don't expect it to help).
So for a single-marker draw (e.g. a tick) we just bypass the cache.

Ah, I don't think I noticed that and didn't implement it. The downside of doing that is it then depends on how we draw ticks, and there is of course some hope that we can refactor enough to draw them as a collection in the future.

(Maybe if the design was to lazily populate the cache as entries are used then I would have added an explicit check instead to bypass the cache for single-marker draws.)

I thought of this one originally, but I'm not sure how easy it is, since the Agg rasterizer is re-used for both marker cache and the actual drawing, so we'd have to do some careful tracking of state if we switch between them.

We should check how this looks for squares: Do subpixel interpolated edges give the impression of “in between position” or just “blurry”?
Same question for line-like markers like “x” and “+”.

Here is how it looks for those before:

and with this PR:

You may have to click through to view full size.

Looking at the test failure in lib/matplotlib/tests/test_axes.py::test_stairs_fill, it appears that this PR negatively affects the single path-as-draw_marker optimization, since it's no longer snapped. I wonder why this doesn't cause the same problem on mplcairo.

Comparing to mplcairo, both test/ref images that it creates match the new result from this PR (minus the text):

The antialiasing looks really bad with squares in the animation, how does mplcairo do with it?

I see some moire for the squares, but I think that's from scaling down to fit the GitHub comment width. I'm not sure it's so bad at full size, but here is what mplcairo looks like:

Ah, indeed the moire goes away when the video is blown up. But it's still a bit weird, the moire doesn't show up even downscaled with mplcairo?

A conceptual thought without having tested it in detail: There could also be a difference in visual preference between static and animated images. Static images may benefit more from sharp edges, whereas in animations a smooth movement can be more important.