Ok -- sorry about that. It looked pretty good on the quadmesh_demo example, but I suppose that's just by accident due to the nature of the data. By this assessment, we should probably back out this hack in pcolormesh as well.
Curiously, though, Rob says this is new behavior... Cheers, Mike Eric Firing wrote: > Michael Droettboom wrote: >> Rob Hetland wrote: >>> When I do a pcolor, there are white lines between the patches that >>> cause strange moray patterns, even when saved to a png. The >>> attached sample shows what I mean. Notice the strange coffee-cup >>> ring, where the pattern goes away. This is new behavior. >>> Unfortunately, I haven't been paying enough attention to the devel >>> list to know what the changes that cause this might be. >> The quads need to be enlarged by about 1 pixel, and the easiest way >> to do this is to give them an edge of width 1 pixel. The pcolormesh >> code has had this fix for a while, but it was overlooked for pcolor. >> (Both of which were virtually rewritten for 0.98, which is why this >> is a regression from 0.91). >> >> I have fixed this in SVN. > > Mike, > > Not exactly. This is a very old problem and an old attempted > solution. I struggled with it a long time ago, and among the various > combinations of backends and antialiasing settings, I never found a > completely satisfactory solution. I don't know what the best solution > will be, but a linewidth of 1 point is definitely not it. It is > fundamentally wrong--expanding the patch dimensions by 1/144 inch, so > that they overlap--and consequently creates its own artifacts. If you > run the attached script and look at the ps output, you will see > artifacts in the rectangle corners, and some of the tick marks will be > more misplaced than they used to be relative to the rectangle boundaries. > > I'm sorry I don't have a good solution right now and can't look at it > in detail immediately, and I don't mean to dump more work on you. > Let's just consider the issue as open for discussion and > investigation. I can try to get back to it later. > > (It is conceivable that a thinner linewidth will be an adequate > compromise--still a hack, but maybe acceptable--although the last time > I worked on this problem, long before 0.98, I could not get it to work > well under all circumstances.) > > Eric -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel