matplotlib-devel Mailing List for matplotlib

John, David,
The problem is indeed the patch boundaries; here is the workaround:
In [2]:bb = bar(arange(500), rand(500))
In [3]:for b in bb: b.set_linewidth(0)
 ...:
In [4]:draw()
We should probably do something like setting linewidth to zero 
automatically if edgecolor is None, so that the existing edgecolor kwarg 
can be used to achieve this result. And/or add a linewidth kwarg.
Eric
John Hunter wrote:
>>>>>> "David" == David Huard <dav...@gm...> writes:
> 
> David> Hi, When plotting a large amount of bars, like
> 
> >>>> bar(arange(500), rand(500))
> 
> David> the bars seem to overlap and it produces a weird effect.
> 
> David> My feeling is that the culprit is the contour line around
> David> each rectangle, who probably don't scale properly in this
> David> limit. In fact, the problem is maybe not so much that the
> David> contour width doesn't scale, but that the contour is drawn
> David> outside the rectangle.
> 
> David> I'd be glad to submit a patch, but I'd need some directions
> David> (where in the code is the contour drawn ?)
> 
> This is likely due to either antialising of the bar patch.Rectangle
> objects (does it help to turn the antialiased property off?) or
> subpixel rendering (does it help to comment out these lines in
> src/_backend_agg.cpp in the draw_polygon function?)
> 
> //snapto pixel centers
> x = (int)x + 0.5;
> y = (int)y + 0.5;
> 
> JDH
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

>>>>> "David" == David Huard <dav...@gm...> writes:
 David> Hi, When plotting a large amount of bars, like
 >>>> bar(arange(500), rand(500))
 David> the bars seem to overlap and it produces a weird effect.
 David> My feeling is that the culprit is the contour line around
 David> each rectangle, who probably don't scale properly in this
 David> limit. In fact, the problem is maybe not so much that the
 David> contour width doesn't scale, but that the contour is drawn
 David> outside the rectangle.
 David> I'd be glad to submit a patch, but I'd need some directions
 David> (where in the code is the contour drawn ?)
This is likely due to either antialising of the bar patch.Rectangle
objects (does it help to turn the antialiased property off?) or
subpixel rendering (does it help to comment out these lines in
src/_backend_agg.cpp in the draw_polygon function?)
 //snapto pixel centers
 x = (int)x + 0.5;
 y = (int)y + 0.5;
JDH
 

Hi,
When plotting a large amount of bars, like
>>> bar(arange(500), rand(500))
the bars seem to overlap and it produces a weird effect.
My feeling is that the culprit is the contour line around each rectangle,
who probably don't scale properly in this limit. In fact, the problem is
maybe not so much that the contour width doesn't scale, but that the contour
is drawn outside the rectangle.
I'd be glad to submit a patch, but I'd need some directions (where in the
code is the contour drawn ?)
Thanks for matplotlib !
David

Eric Firing schrieb:
> Norbert,
>
> Your change in commenting out almost everything in matplotlibrc was a 
> good one, but I think it had an unintended consequence: it changed the 
> way everything looks because the defaults in __init__.py were not the 
> same as the ones in matplotlibrc. To my eye and on my machine the 
> matplotlibrc defaults are better, and my guess is that this is because 
> over a period of time people tuned the matplotlibrc values but left the 
> __init__.py values alone--after all, they were normally not used. In 
> any case, I went ahead and changed __init__.py to match matplotlibrc.
> 
Thanks! I only did a spot check on some of the values and did not find
any differences. I agree that the values in the old matplotlibrc are
likely to be the more reasonable defaults. Furthermore, anybody who
didn't think about the issue would probably have used these values
anyway, so your changes should give the best backwards compatibility.