Would probably be good to have some tests specifically for this. Different markers, different sizes, different locations and at different resolutions. Does shifting it half a pixel only impact the visual result if rounding would have been an issue?

I also wonder if a similar approach might solve the contourf problem?

Would probably be good to have some tests specifically for this. Different markers, different sizes, different locations and at different resolutions. Does shifting it half a pixel only impact the visual result if rounding would have been an issue?

Once the tests are lowered to zero tolerance in #5307, the existing tests should do that and detect changes of this magnitude. And there are already tests that test all of the different markers (test_axes.test_marker_styles). I think it best not to add additional tests in this case.

I also wonder if a similar approach might solve the contourf problem?

I don't think so. I've already experimented with snapping to solve that problem some time ago, and it doesn't help.

Does this address #3400 ?

And when we lower the tolerance to zero, and images are remade en masse, are we going to be able to verify every single marker is drawn correctly? Also, we don't have all that many tests that use different resolutions?

I would love to see test images made at fairly low resolutions that draws lines like you have above and plots markers at their intersections. Having it at a low resolution would make it visually obvious that something is wrong.

And when we lower the tolerance to zero, and images are remade en masse, are we going to be able to verify every single marker is drawn correctly?

Yes. That was why I built the comparison tool in #5521, to make that kind of thing much easier.

Also, we don't have all that many tests that use different resolutions?

That's true.

I would love to see test images made at fairly low resolutions that draws lines like you have above and plots markers at their intersections. Having it at a low resolution would make it visually obvious that something is wrong.

That's a good point.

Does this address #3400 ?

I think not, unfortunately -- addressing that requires the line and the marker line to know about each other and snap in sync. We don't really have that kind of global knowledge. But #3400 only really becomes a problem if the user customizes the line width or marker edge width to be a mismatch of even/odd sizes.

Was test_axes/stackplot_test_baseline.png really supposed to change here?

Was test_axes/stackplot_test_baseline.png really supposed to change here?

Yep. For reasons that are rather obscure, stackplots end up going through the draw_marker code path on Agg.

So, the stackplots are polygons, right? Would it make sense to treat
contourf polygons similarly?

I am being overly hopeful, but the stackplots do look better now, so I just
wanted to make sure that this possibility has been considered.
On Dec 2, 2015 6:27 PM, "Michael Droettboom" notifications@github.com
wrote:

Was test_axes/stackplot_test_baseline.png really supposed to change here?

Yep. For reasons that are rather obscure, stackplots end up going through
the draw_marker code path on Agg.

—
Reply to this email directly or view it on GitHub
#5603 (comment)
.

backported to 1.5.x as 34c7dad