I have finally managed to test against TkAgg, and the faint white lines do not appear to occur. So, as far as I can tell (no clue about Macs), the GTKCairo, pdf and svg backends have this display bug. Shall I file a bug report for this and another for the misaligned title?
Ben Root On Tue, Jun 1, 2010 at 1:07 PM, Benjamin Root <ben.r...@ou.edu> wrote: > Correction -- the problem with pcolormesh and the faint white lines are > occurring for pdf and svg files, *not* eps files as I originally stated. I > am also checking a number of display backends and found that the problem > occurs for GTKCairo. I am sure it also happens for TkAgg, but I can not > confirm that right now. I am unable to test the Mac backends, though. > > On a side note, when testing the backends, I noticed that GTKCairo was > *slow* for displaying the figures. Also, the GTK backend produced > misaligned titles. I can start a new thread about the misaligned titles, if > someone wishes. > > Ben Root > > > On Tue, Jun 1, 2010 at 11:05 AM, Benjamin Root <ben.r...@ou.edu> wrote: > >> >> >> On Tue, Jun 1, 2010 at 9:39 AM, Ryan May <rma...@gmail.com> wrote: >> >>> On Mon, May 31, 2010 at 11:28 AM, Benjamin Root <ben.r...@ou.edu> wrote: >>> > Markus, >>> > >>> > That is good to know that it has been fixed. As for the difference in >>> > pcolor and pcolormesh, I think it has to do with the fact that >>> pcolormesh is >>> > composed of many lines while pcolor is composed of many polygons. It >>> is >>> > probably more efficient to rasterize polygons than lines. >>> >>> To be blunt, this makes no sense whatsoever. First, pcolormesh and >>> pcolor differ in that it pcolor uses a generic PolyCollection to draw >>> the quads, while pcolormesh uses a quadmesh object, which can be more >>> efficient at the cost of generality, as it only needs to render a set >>> of identical quads. Second, if you're talking rasterized drawing, in >>> the end what gets written to a file is a 2D array of RGBA values. It >>> doesn't matter what you use to produce the results: identical image on >>> the screen -> identical array in file. It's possible that there are >>> slight differences that you can't really see that produce different >>> arrays, but that won't cause a factor of 8 difference in size. My >>> guess is that pcolormesh isn't rasterizing properly. >>> >>> Indeed, you are right that lines aren't drawn. I have looked back at the >> images produced by my test script that I posted to this thread and I see >> where I got confused. The pcolormesh result in pdf and eps files have very >> faint white blocks around each quad. At high enough data resolution, the >> color part of the quads look like lines while the white lines look like >> dots. This happens regardless of using rasterized=True or not, and I don't >> think it is visible in png files (although I am testing some very high >> resolution png files to verify). >> >> Ben Root >> > >
------------------------------------------------------------------------------
_______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
