At one point in history, the Agg backend would not do NaN removal on
paths with curves -- but it looks like that's been inadvertently lost,
probably in all the shuffling wrt simplification that went on, since
simplification has similar restrictions. So at present, we have
problems because it's passing curves with too few points to Agg, since
it removes points with NaNs, but not necessarily the entire curve
segment. In any case, even passing the vertices as-is (without NaNs
removed) to Agg still results in an infinite loop.
The "real" fix, IMO, is to make the NaN-handling code aware of curves,
which requires doing a look-ahead. That is -- if a curve segment has
any NaNs at all, remove the entire curve segment. I've thought about
this for a bit, but now here's some impetus to finally implement it. :)
Mike
John Hunter wrote:
> On Fri, Jan 23, 2009 at 2:06 PM, Michael Hearne <mhea...@usgs.gov> wrote:
>
>> I have discovered, from the mailing list, the easy way to draw a circle
>> in linear space:
>> ...snip
>> cx = 700
>> cy = 700
>> r = 1000
>>
>> xmin = cx - r
>> xmax = cx + r
>> ymin = cy - r
>> ymax = cy + r
>>
>> cir = Circle( (cx,cx), radius=r,facecolor='w',edgecolor='b')
>> a = gca()
>> a.add_patch(cir)
>>
>> axis([xmin,xmax,ymin,ymax])
>> axis('equal')
>>
>> How can I plot a circle in log space?
>>
>
> The problem is that your circle has negative vertices since cx-r<0 and
> cy-r<0. When this happens, mpl is transforming the vertices with log
> coordinates and getting nans, as it should. The problem is that these
> nan vertices are getting passed to the agg backend, and when the
> vertex type is curve4, as it is for a circle, agg gets stuck in an
> infinite recursion in the spline code. I suspect this is because the
> recursion expects the comparison operator on the vertices to be well
> behaved, but it is not in the presence of nans. The function in
> question is agg_curve.cpp curve4_div::recursive_bezier. There is a
> "maximum recursion limit" in that function, but for some reason I
> don't understand, it is not breaking out of the function.
>
> I committed a simple "fix" to the branch and the trunk to simply drop
> any patch where any of the vertices are nans
>
> if not np.isnan(tpath.vertices).any():
> renderer.draw_path(gc, tpath, affine, rgbFace)
>
> We might be able to do better than this -- is there a well defined way
> to deal with patches where any of the transformed vertices are nans?
> For simple polygons (no splines vertices), we could plot the polygon
> with all the nan containing vertices removed, though in some cases
> this could be a strange object -- this appears to be what was
> happening by default with CirclePolygon with negative vertices but I
> think this was mostly fortuitous that agg dealt with the nans
> gracefully in this case. But for patches containing curve vertices,
> this seems like a bad idea, since simply dropping vertices from a
> spline curve is not defined.
>
> I'm including below some sample code that shows the bug on Agg
>
> JDH
>
> import matplotlib
> matplotlib.use('Agg')
>
> import matplotlib.pyplot as plt
> import matplotlib.patches as patches
> cx = 700
> cy = 700
> r = 1000
>
> fig = plt.figure()
> ax = fig.add_subplot(111)
>
> #cir = patches.CirclePolygon( (cx,cy), radius=r,facecolor='w',edgecolor='b')
> cir = patches.Circle( (cx,cy), radius=r,facecolor='w',edgecolor='b')
> ax.add_patch(cir)
> ax.set_yscale('log')
> fig.savefig('test')
> plt.show()
>
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
