Michael Droettboom wrote: > Charlie Moad wrote: >> I did some more digging and it looks like this changed with the >> transforms. curve4 is now being called instead of arc_to, which uses >> beziers. > > curve4 is the way to specify a cubic bezier curve, so it is functionally > equivalent to the old arc_to approach (but easier to be consistent > across backends, which is why the change was made).
Sorry, I was confused... John recently fixed the ellipse drawing on the trunk (which was broken wrt rotated ellipses), to use bezier curves instead of agg's arc_to. Agg's arc_to itself isn't broken wrt to James' problem -- in fact it does provide sufficient accuracy -- it was the way mpl used arc_to in previous incarnations that was broken wrt rotated ellipses. Unfortunately, the fix for that reduced accuracy to noticable levels on these really large ellipses. So, in order to have the best of both worlds, I agree the 8-spline approximation seems like the way to go. (But the changes on the transforms branch are irrelevant here -- they do essentially the same thing the trunk currently does: that is 4 spline approximation of the circle). > I'm attempting to implement the 8-spline approximation and I'll let you > know how that goes. I have 8-spline approximation working on the trunk and on the transforms branch. (r4679) In the process, I uncovered another bug (which I suppose should have been obvious when ellipses were updated last time, but went right by me) -- ellipses don't work at all in the pdf, svg or cairo backends, since they don't implement draw_path. I'll file a placeholder bug for this, and hopefully get to it, time permitting. > In any case, I think we should add James' example > to our unit tests, since it illustrates a case where my assumptions > about how ellipses would be used breaks down. Also done. Cheers, Mike >> On Dec 9, 2007 10:11 AM, Charlie Moad <[EMAIL PROTECTED]> wrote: >>> I found a great doc I am linking. The 4 spline method we are using >>> has an error tolerance of 2.7*10^-4, which I am pretty sure is coming >>> into play here. If we move to an 8 spline approach, it would reduce >>> the error a few orders of magnitude. >>> >>> http://www.tinaja.com/glib/ellipse4.pdf >>> >>> - Charlie >>> >>> >>> >>> On Dec 8, 2007 9:09 AM, John Hunter <[EMAIL PROTECTED]> wrote: >>>> On Dec 7, 2007 6:02 PM, James Evans <[EMAIL PROTECTED]> wrote: >>>> >>>>> There appears to be an issue with the agg backend with how it is drawing >>>>> ellipses (or maybe it is how matplotlib uses agg), but the attached script >>>>> shows how a point, which should be coincident with the center circle, but >>>>> it >>>>> is not. The second plot shows the same data, but using a custom (and much >>>>> slower) algorithm for drawing the ellipses, where the point is properly >>>>> coincident. >>>> Thanks for the test case James -- I will try and sort this out ASAP. >>>> Michael, do you see the same on the transforms branch? The branch is >>>> on a newer version of agg so if not, perhaps it is a simple matter of >>>> upgrading agg on the trunk. I'm travelling currently bt will be back >>>> omorrow and ill look at this ASAP. >>>> >>>> JDH >>>> >>>> ------------------------------------------------------------------------- >>>> SF.Net email is sponsored by: >>>> 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 >>>> >> ------------------------------------------------------------------------- >> SF.Net email is sponsored by: >> 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 > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA ------------------------------------------------------------------------- SF.Net email is sponsored by: 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
