Fix single pixel markers - #695

Thanks Mike. This is really fast! I'll give it a try once I figure out how to check out from github and how not to mess up with my current mpl installation.

As I tested just now, the Agg backend works perfectly. Any fix for postscript output? It's still 2x2 squares.

Also, in this branch the subplot configuration tool has some problem. When making adjustment and the screen being redrawn, the indicating bar changes from a blue rectangle to a blue triangle. I wish I can attach a screenshot here.

My bad. pixels in postscript are indeed smaller than before, just not single pixel as the ticker line.

For the postscript (or any vector backend) there's no way to enforce strictly one pixel. All we can do is have it be one "dot" in whatever the "dots per inch" is set to. By that measurement, I believe it's correct, but let me know if you see otherwise.

My only concern here is that the center position of the original marker and the new one is shifted by (0.5, 0.5) pixel.
With the snapping thing happen, I'm not sure why we need that shift or if that shift has any consequences.

I did some test.

plot([0.012], [0.4], "k,")
xlim(0,1); ylim(0,1)

As one of y-ticks is at 0.4, I expected the maker will be aligned with the tickline, but it does not.

AGG backend

PS backend

If I adjust the transformation to

Affine2D().translate(-0.5, -0.5).scale(0.5, 0.5)

which I tend to think is a right transformation.
I get a expected result for the ps backend, but the point in AGG backend is blurred over 2x2 pixels and the center is slightly off. Maybe this has something to do with the snapping?

Also, note that the pixel size in PS backend is a bit larger than the tick line width. I guess this is expected as we are stroking a square of 0.5x0.5 pixel with 1 pixel thick line, i.e., resulting in a 1.5x1.5 pixel square. Maybe we can reduce the square size a bit more?

Snapping is turned off for single pixel markers. By definition for Agg, the center of a pixel is (0.5, 0.5), so the only way to draw a single pixel is by defining that as the center. We should probably fix the ticks to match this rather than the other way around, though we'll have to see what consequences that has.

Where are we on this? Does the snapping fix have anything to do with this?

I've been working with this, but it's kind of a rat's nest down there. I'll see what @leejjoon's snapping fixes do to this.

@mdboom, should the translation to a pixel center of (0.5, 0.5) be done in the backckend level? I'm not sure why we need that shift for ps or pdf backend.

I think I have a solution here now. Can you test?

It looks perfect in PS. In the png version, there is no gap between the pixel marker and the tick. Also, it doesn't show up as a single pixel. Then again, I guess that could be due to compression?

Hmm... it should show up as a single pixel -- PNG uses lossless compression -- that's puzzling. Can you put a picture up somewhere (or e-mail to me?)

Here: http://dl.dropbox.com/u/7325604/pixel_marker_test.png

Hmm... I'm stumped. Anything set in your matplotlibrc?

Same result after getting rid of my modified matplotlibrc file. I should also note that in GTKAgg, the pixel point looks to be located exactly one pixel north of the tick mark (when doing show()). It didn't look like that for TKAgg.

Dumb question: Are you sure you're running the latest version? You seem to be describing the behavior before today's latest round of changes.

I am running your branch off based off of v1.1.x, which is what this PR is set for. I will note that I had to do some round-about way of getting it because (even though I have your repo for a remote) I couldn't just fetch your branch. I had to create my own branch (off of v1.1.x) and pull your branch. But the log looks right to me.

Ok -- one of my changes didn't make it in. Please try again now -- sorry for the wild goose chase.

Woot! Success! It looks perfect in show() (GTKAgg and TkAgg), png, ps, pdf and svg.

Great! Merging...

Looks like merging this into master needs some work. This is holding up the merging of the doc fixes as well.

I'll take a look

Seems to be resolved now.

did you push your changes up? I don't see any change

I see it now...

So do I, and I now have that all taken care of. Thanks!

As @leejjoon pointed out in #726, this introduces an offset in the markers. It also introduces an offset in the clipbox. Working on this now.