I wonder whether it is just a limitation on the ability of antialiasing to deliver a visual impression of sub-pixel accuracy. The steppiness is at the one-pixel level, but it doesn't look like simple pixel-snapping.

Turning snapping off does not help that much. I wonder if this is related to the way we 'stamp' the markers?

attn @mdboom

Yes, it's definitely related to how we stamp the markers. We don't do individual subpixel positioning for the markers. We could do that but it would be significantly slower (so should be a user-configurable option).

I'm also suffering from this issue. See the attached script and image for an example of what happens to a grid of evenly spaced markers. This level of quality is simply not acceptable for professional use - it looks like something out of the 1980s, but this 2017, and subpixel positioning is no longer optional.

grid.py.txt

Could you repost that example. The link appears to be broken.

I would be curious if this is something that could be resolved with the Cairo rework?

@WeatherGod It is indeed solved by mpl_cairo (in fact this was one of the original motivations for writing it). See second example at https://gitter.im/matplotlib/matplotlib?at=5963202789aea4761d81a829. (You even commenter right under it :-))
As a side note mpl_cairo also stamps the markers much faster (there's a timing script in the examples).

I'm sure you can technically make it work in Agg... if someone actually understands the Agg rendering code paths (I gave up due to complete lack of documentation on Agg's side). The relevant part, which is at https://github.com/anntzer/mpl_cairo/blob/master/src/_mpl_cairo.cpp#L540 (cache preparation) and https://github.com/anntzer/mpl_cairo/blob/master/src/_mpl_cairo.cpp#L588 (marker stamping), should be fairly self explanatory if you know C++ -- I make a cache of renderered markers with various subpixel offsets (decided according to the path.simplify_theshold, because why not) and then the stamping loop just needs to pull out the right one each time.

There's some discussion about using a recent g++ on a manylinux1 docker, which also involves statically linking a recent libstdc++ into a manylinux1 wheel, so that's apparently doable too... but tbh it's not very high on my priority list now.

There is a nice visualization of this issue brought up in this Stackoverflow question.

Running this with TkCairo shows the same issue as with TkAgg in the saved animation.
Interestingly the scatter animates smoothly on screen with Cairo backend, while there is no difference between the animation on screen and the saved gif for Agg backend. (@anntzer Is this difference to be expected?)

Code for reproduction:

import numpy as np
import matplotlib
matplotlib.use("TkCairo")
import matplotlib.pyplot as plt
from matplotlib.collections import PatchCollection
from matplotlib.animation import FuncAnimation

x, y = np.meshgrid(np.linspace(-1,1,31),np.linspace(-1,1,31))

fig, (ax1,ax2) = plt.subplots(ncols=2, figsize=(5,2.8))
fig.subplots_adjust(.02,.02,.98,.9,.03,.03)
fig.suptitle(matplotlib.get_backend())
ax1.set_title("scatter")
ax2.set_title("PatchCollection")
### Scatter
sc = ax1.scatter(x,y,s=2)
### PatchCollection
patches=[]
for i in range(x.shape[0]):
    for j in range(x.shape[1]):
        patches.append(plt.Circle((x[i,j],y[i,j]),0.015))
        
class UpdatablePatchCollection(PatchCollection):
    def __init__(self, patches, *args, **kwargs):
        self.patches = patches
        PatchCollection.__init__(self, patches, *args, **kwargs)
    def get_paths(self):
        self.set_paths(self.patches)
        return self._paths
    
pc = UpdatablePatchCollection(patches)
ax2.add_collection(pc)


for ax in (ax1,ax2):
    ax.axis("off")
    ax.set_xlim(-1.2,1.2)
    ax.set_ylim(-1.2,1.2)
    ax.set_aspect('equal')

def generator():
    X=np.copy(x); Y=np.copy(y)
    for i in range(100):
        X += 0.0015*np.cos(x+3*y)
        Y += 0.0015*np.sin(6*x-4*y)
        yield (X,Y)

def animate(i): 
    x,y = i
    # update scatter
    sc.set_offsets(np.c_[x.flatten(),y.flatten()])
    # update PatchCollection
    for circle, xi,yi in zip(patches, x.flatten(),y.flatten()):
        circle.center = (xi,yi)
    pc.pchanged()

ani = FuncAnimation(fig, animate, frames=generator, interval=50, repeat=False)
ani.save("skewedgrid{}.gif".format(matplotlib.get_backend()), writer="imagemagick")
plt.show()

The difference is due to the fact that when saving an animation, we internally fallback on agg, because backend_cairo did not implement a way to dump the raw buffer. #10828 fixes that issue.

You may also be interested in https://github.com/anntzer/mplcairo for a faster version...

Just to make sure, these weird horizontal and vertical patterns below are due to this issue basically, right?

import numpy as np
import matplotlib.pyplot as plt

x = np.tile(np.arange(100), 100)
y = np.repeat(np.arange(100), 100)

f, ax = plt.subplots(figsize=(7, 7))
ax.scatter(x, y, s=1, c='k')

Yes.

Is there really an action item for this? If not, I'll leave open but un-milestone.

Yes, instead of generating 1 stamp and snapping to the nearest pixel, generate N and snap to nearest fraction of a pixel.

not sure if related or said before, but either:

• the pixel marker position is 1 pixel too high when other markers are fine
• other markers positions are 1 pixel too low, while the pixel marker position if fine
  (depending on if the axis is positioned correctly as well)

example:

plt.xlim(0, 3)
plt.ylim(0, 3)
plt.plot(.05, 1, ',b')
plt.plot(.1, 1, '.b')
plt.plot(.2, 1, 'ob', ms=10, mew=1)
plt.plot(.3, 1, ',b')
plt.plot(.3, 1, 'or', fillstyle='none', ms=10, mew=1)
plt.plot(.4, 1, '.b', ms=9)
plt.plot(.4, 1, 'or', fillstyle='none', ms=10, mew=1)    
plt.savefig('tst.png', dpi=100)

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!