John Hunter wrote: > On Dec 10, 2007 10:25 AM, Ted Drain <[EMAIL PROTECTED]> wrote: > >> I don't know if the current MPL architecture can support this but it >> would be nice if it worked that way. We have people making decisions >> based on what these plots show that affect spacecraft worth hundreds >> of millions of dollars so it's important that we're plotting things >> accurately. > > We can support this, but I think we would do this with an arc class > rather than an ellipse class, and write a special case class that is > viewlim aware.
I agree -- I think there are two uses cases for ellipse that are in conflict here. One is these large ellipses, the other is for things like scatter plots, where speed and file size is more important than accuracy. My mind was probably stuck on the latter as I've worked along the transforms branch. > A simple example of a line that has analogous > behavior is examples/clippedline.py, which clips the points outside > the viewport and draws in a different style according to the > resolution of the viewlim. The reason I think it would be preferable > to use an arc here is because we won't have to worry about filling the > thing when we only approximate a section of it. You could feed in a > 360 degree elliptical arc and then zoom into a portion of it. > > With the 8 point ellipse as is, and the addition of an arc class that > does 4 or 8 point approximation within the zoom limits, should that > serve your requirements? As a possible starting point, the transforms branch already has arc-approximation-by-cubic-bezier-spline code. It determines the number of splines to use based on the radians included in the arc, which is clearly not what we want here. But it should be reasonably straightforward to make that some fixed number and draw the arc between the edges of the axes. Or, alternatively, (and maybe this is what John is suggesting), the arc could be approximated by line segments (with the number of segments something like the number of pixels across the axes). To my naive mind, that seems more verifiable -- or at least it puts the responsibility of getting this right all in one place. IMHO, these spline approximation tricks are all just with the aim of pushing curve rendering deeper into the backends for speed and file size improvements. But obviously there needs to be a way around it when it matters. Cheers, Mike -- 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
