All of these sound like good ideas to me. Just for some history: the original reason we worked w/ John to get an Ellipse primitive in (vs a normal line plot of sampled points) were to: - improve ellipse plotting speeds (we plot a LOT of them at once) - improve post script output
Ted At 08:53 AM 12/10/2007, Michael Droettboom wrote: >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 Ted Drain Jet Propulsion Laboratory [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
