You can subscribe to this list here.
2003 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(1) 
_{Nov}
(33) 
_{Dec}
(20) 

2004 
_{Jan}
(7) 
_{Feb}
(44) 
_{Mar}
(51) 
_{Apr}
(43) 
_{May}
(43) 
_{Jun}
(36) 
_{Jul}
(61) 
_{Aug}
(44) 
_{Sep}
(25) 
_{Oct}
(82) 
_{Nov}
(97) 
_{Dec}
(47) 
2005 
_{Jan}
(77) 
_{Feb}
(143) 
_{Mar}
(42) 
_{Apr}
(31) 
_{May}
(93) 
_{Jun}
(93) 
_{Jul}
(35) 
_{Aug}
(78) 
_{Sep}
(56) 
_{Oct}
(44) 
_{Nov}
(72) 
_{Dec}
(75) 
2006 
_{Jan}
(116) 
_{Feb}
(99) 
_{Mar}
(181) 
_{Apr}
(171) 
_{May}
(112) 
_{Jun}
(86) 
_{Jul}
(91) 
_{Aug}
(111) 
_{Sep}
(77) 
_{Oct}
(72) 
_{Nov}
(57) 
_{Dec}
(51) 
2007 
_{Jan}
(64) 
_{Feb}
(116) 
_{Mar}
(70) 
_{Apr}
(74) 
_{May}
(53) 
_{Jun}
(40) 
_{Jul}
(519) 
_{Aug}
(151) 
_{Sep}
(132) 
_{Oct}
(74) 
_{Nov}
(282) 
_{Dec}
(190) 
2008 
_{Jan}
(141) 
_{Feb}
(67) 
_{Mar}
(69) 
_{Apr}
(96) 
_{May}
(227) 
_{Jun}
(404) 
_{Jul}
(399) 
_{Aug}
(96) 
_{Sep}
(120) 
_{Oct}
(205) 
_{Nov}
(126) 
_{Dec}
(261) 
2009 
_{Jan}
(136) 
_{Feb}
(136) 
_{Mar}
(119) 
_{Apr}
(124) 
_{May}
(155) 
_{Jun}
(98) 
_{Jul}
(136) 
_{Aug}
(292) 
_{Sep}
(174) 
_{Oct}
(126) 
_{Nov}
(126) 
_{Dec}
(79) 
2010 
_{Jan}
(109) 
_{Feb}
(83) 
_{Mar}
(139) 
_{Apr}
(91) 
_{May}
(79) 
_{Jun}
(164) 
_{Jul}
(184) 
_{Aug}
(146) 
_{Sep}
(163) 
_{Oct}
(128) 
_{Nov}
(70) 
_{Dec}
(73) 
2011 
_{Jan}
(235) 
_{Feb}
(165) 
_{Mar}
(147) 
_{Apr}
(86) 
_{May}
(74) 
_{Jun}
(118) 
_{Jul}
(65) 
_{Aug}
(75) 
_{Sep}
(162) 
_{Oct}
(94) 
_{Nov}
(48) 
_{Dec}
(44) 
2012 
_{Jan}
(49) 
_{Feb}
(40) 
_{Mar}
(88) 
_{Apr}
(35) 
_{May}
(52) 
_{Jun}
(69) 
_{Jul}
(90) 
_{Aug}
(123) 
_{Sep}
(112) 
_{Oct}
(120) 
_{Nov}
(105) 
_{Dec}
(116) 
2013 
_{Jan}
(76) 
_{Feb}
(26) 
_{Mar}
(78) 
_{Apr}
(43) 
_{May}
(61) 
_{Jun}
(53) 
_{Jul}
(147) 
_{Aug}
(85) 
_{Sep}
(83) 
_{Oct}
(122) 
_{Nov}
(18) 
_{Dec}
(27) 
2014 
_{Jan}
(58) 
_{Feb}
(25) 
_{Mar}
(49) 
_{Apr}
(17) 
_{May}
(29) 
_{Jun}
(39) 
_{Jul}
(53) 
_{Aug}
(52) 
_{Sep}
(35) 
_{Oct}
(47) 
_{Nov}
(110) 
_{Dec}
(27) 
2015 
_{Jan}
(50) 
_{Feb}
(93) 
_{Mar}
(96) 
_{Apr}
(30) 
_{May}
(55) 
_{Jun}
(83) 
_{Jul}
(44) 
_{Aug}
(8) 
_{Sep}
(5) 
_{Oct}

_{Nov}
(1) 
_{Dec}
(1) 
2016 
_{Jan}

_{Feb}

_{Mar}
(1) 
_{Apr}

_{May}

_{Jun}
(2) 
_{Jul}

_{Aug}
(3) 
_{Sep}
(1) 
_{Oct}
(3) 
_{Nov}

_{Dec}

2017 
_{Jan}

_{Feb}
(5) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(3) 
_{Aug}

_{Sep}
(7) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1
(3) 
2
(3) 
3
(26) 
4
(12) 
5
(17) 
6
(20) 
7

8
(2) 
9
(2) 
10
(15) 
11
(10) 
12
(21) 
13
(20) 
14
(8) 
15
(6) 
16
(6) 
17
(3) 
18
(2) 
19
(1) 
20
(2) 
21
(4) 
22

23

24

25
(1) 
26
(3) 
27
(1) 
28

29

30
(2) 
31






From: John Hunter <jdh2358@gm...>  20071211 21:38:58

On Dec 11, 2007 3:24 PM, Ted Drain <ted.drain@...> wrote: > Thanks! That looks like a great solution. We'll take a look at it this > week and try to beat on it w/ some more test cases. Very nice work Michael  I tried updating from your branch but it looks like maybe you haven't committed yet, as the last log entry I am seeing is: r4694  mdboom  20071210 13:53:12 0600 (Mon, 10 Dec 2007)  2 lines Simplify even more JDH 
From: Ted Drain <ted.drain@jp...>  20071211 21:25:00

Michael, Thanks! That looks like a great solution. We'll take a look at it this week and try to beat on it w/ some more test cases. Ted At 12:46 PM 12/11/2007, Michael Droettboom wrote: >Sorry  correct attachment this time. > >Michael Droettboom wrote: >>I have a working draft of something that may work for this problem >>on the transforms branch. I am happy to backport this to the >>trunk, but that will require some effort, as the implementation >>relies on many of the new geometric utilities on the branch that >>would also have to be brought over. It may be some time until the >>branch is ready for production use, but if you are able to use it >>to experiment with this approach to this specific problem, that >>would certainly make my life easier, so I don't have to do the >>backporting work more than once. >>Attached is a plot comparing the new approach (above) vs. a >>750edge polygonal approximation for the ellipses (based directly >>on James Evans' example). Here's a description of what it does: >> >> Ellipses are normally drawn using an approximation that uses >> eight cubic bezier splines. The error of this approximation >> is 1.89818e6, according to this unverified source: >> Lancaster, Don. Approximating a Circle or an Ellipse Using >> Four Bezier Cubic Splines. >> http://www.tinaja.com/glib/ellipse4.pdf >> There is a use case where very large ellipses must be drawn >> with very high accuracy, and it is too expensive to render the >> entire ellipse with enough segments (either splines or line >> segments). Therefore, in the case where either radius of the >> ellipse is large enough that the error of the spline >> approximation will be visible (greater than one pixel offset >> from the ideal), a different technique is used. >> In that case, only the visible parts of the ellipse are drawn, >> with each visible arc using a fixed number of spline segments >> (8). The algorithm proceeds as follows: >> 1. The points where the ellipse intersects the axes bounding >> box are located. (This is done be performing an inverse >> transformation on the axes bbox such that it is relative to >> the unit circle  this makes the intersection calculation >> much easier than doing rotated ellipse intersection >> directly). >> This uses the "line intersecting a circle" algorithm from: >> Vince, John. Geometry for Computer Graphics: Formulae, >> Examples & Proofs. London: SpringerVerlag, 2005. >> 2. The angles of each of the intersection points are >> calculated. >> 3. Proceeding counterclockwise starting in the positive >> xdirection, each of the visible arcsegments between the >> pairs of vertices are drawn using the bezier arc >> approximation technique implemented in Path.arc(). >> >>Cheers, >>Mike >> >>Ted Drain wrote: >>>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 <ted.drain@...> 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 >>>>arcapproximationbycubicbezierspline 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 >>>>_______________________________________________ >>>>Matplotlibdevel mailing list >>>>Matplotlibdevel@... >>>>https://lists.sourceforge.net/lists/listinfo/matplotlibdevel >>> >>>Ted Drain Jet Propulsion Laboratory ted.drain@... >>> >>> >>> >>>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 >>>_______________________________________________ >>>Matplotlibdevel mailing list >>>Matplotlibdevel@... >>>https://lists.sourceforge.net/lists/listinfo/matplotlibdevel >> >> >> >> >> >>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 >> >> >>_______________________________________________ >>Matplotlibdevel mailing list >>Matplotlibdevel@... >>https://lists.sourceforge.net/lists/listinfo/matplotlibdevel > > >Michael Droettboom >Science Software Branch >Operations and Engineering Division >Space Telescope Science Institute >Operated by AURA for NASA > > 
From: Michael Droettboom <mdroe@st...>  20071211 20:48:01

And an actually interesting part of the plot... ;) Michael Droettboom wrote: > Sorry  correct attachment this time. > > Michael Droettboom wrote: >> I have a working draft of something that may work for this problem on >> the transforms branch. I am happy to backport this to the trunk, but >> that will require some effort, as the implementation relies on many of >> the new geometric utilities on the branch that would also have to be >> brought over. It may be some time until the branch is ready for >> production use, but if you are able to use it to experiment with this >> approach to this specific problem, that would certainly make my life >> easier, so I don't have to do the backporting work more than once. >> >> Attached is a plot comparing the new approach (above) vs. a 750edge >> polygonal approximation for the ellipses (based directly on James >> Evans' example). Here's a description of what it does: >> >> >> Ellipses are normally drawn using an approximation that uses >> eight cubic bezier splines. The error of this approximation >> is 1.89818e6, according to this unverified source: >> >> Lancaster, Don. Approximating a Circle or an Ellipse Using >> Four Bezier Cubic Splines. >> >> http://www.tinaja.com/glib/ellipse4.pdf >> >> There is a use case where very large ellipses must be drawn >> with very high accuracy, and it is too expensive to render the >> entire ellipse with enough segments (either splines or line >> segments). Therefore, in the case where either radius of the >> ellipse is large enough that the error of the spline >> approximation will be visible (greater than one pixel offset >> from the ideal), a different technique is used. >> >> In that case, only the visible parts of the ellipse are drawn, >> with each visible arc using a fixed number of spline segments >> (8). The algorithm proceeds as follows: >> >> 1. The points where the ellipse intersects the axes bounding >> box are located. (This is done be performing an inverse >> transformation on the axes bbox such that it is relative to >> the unit circle  this makes the intersection calculation >> much easier than doing rotated ellipse intersection >> directly). >> >> This uses the "line intersecting a circle" algorithm from: >> >> Vince, John. Geometry for Computer Graphics: Formulae, >> Examples & Proofs. London: SpringerVerlag, 2005. >> >> 2. The angles of each of the intersection points are >> calculated. >> >> 3. Proceeding counterclockwise starting in the positive >> xdirection, each of the visible arcsegments between the >> pairs of vertices are drawn using the bezier arc >> approximation technique implemented in Path.arc(). >> >> >> Cheers, >> Mike >> >> >> Ted Drain wrote: >>> 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 <ted.drain@...> 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 >>>> arcapproximationbycubicbezierspline 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 >>>> _______________________________________________ >>>> Matplotlibdevel mailing list >>>> Matplotlibdevel@... >>>> https://lists.sourceforge.net/lists/listinfo/matplotlibdevel >>> >>> Ted Drain Jet Propulsion Laboratory ted.drain@... >>> >>>  >>> >>> 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 >>> _______________________________________________ >>> Matplotlibdevel mailing list >>> Matplotlibdevel@... >>> https://lists.sourceforge.net/lists/listinfo/matplotlibdevel >> >> >>  >> >> >>  >> >>  >> 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 >> >> >>  >> >> _______________________________________________ >> Matplotlibdevel mailing list >> Matplotlibdevel@... >> https://lists.sourceforge.net/lists/listinfo/matplotlibdevel > > >  > > >  > >  > 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 > > >  > > _______________________________________________ > Matplotlibdevel mailing list > Matplotlibdevel@... > https://lists.sourceforge.net/lists/listinfo/matplotlibdevel  Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA 
From: Michael Droettboom <mdroe@st...>  20071211 20:46:29

Sorry  correct attachment this time. Michael Droettboom wrote: > I have a working draft of something that may work for this problem on > the transforms branch. I am happy to backport this to the trunk, but > that will require some effort, as the implementation relies on many of > the new geometric utilities on the branch that would also have to be > brought over. It may be some time until the branch is ready for > production use, but if you are able to use it to experiment with this > approach to this specific problem, that would certainly make my life > easier, so I don't have to do the backporting work more than once. > > Attached is a plot comparing the new approach (above) vs. a 750edge > polygonal approximation for the ellipses (based directly on James Evans' > example). Here's a description of what it does: > > > Ellipses are normally drawn using an approximation that uses > eight cubic bezier splines. The error of this approximation > is 1.89818e6, according to this unverified source: > > Lancaster, Don. Approximating a Circle or an Ellipse Using > Four Bezier Cubic Splines. > > http://www.tinaja.com/glib/ellipse4.pdf > > There is a use case where very large ellipses must be drawn > with very high accuracy, and it is too expensive to render the > entire ellipse with enough segments (either splines or line > segments). Therefore, in the case where either radius of the > ellipse is large enough that the error of the spline > approximation will be visible (greater than one pixel offset > from the ideal), a different technique is used. > > In that case, only the visible parts of the ellipse are drawn, > with each visible arc using a fixed number of spline segments > (8). The algorithm proceeds as follows: > > 1. The points where the ellipse intersects the axes bounding > box are located. (This is done be performing an inverse > transformation on the axes bbox such that it is relative to > the unit circle  this makes the intersection calculation > much easier than doing rotated ellipse intersection > directly). > > This uses the "line intersecting a circle" algorithm from: > > Vince, John. Geometry for Computer Graphics: Formulae, > Examples & Proofs. London: SpringerVerlag, 2005. > > 2. The angles of each of the intersection points are > calculated. > > 3. Proceeding counterclockwise starting in the positive > xdirection, each of the visible arcsegments between the > pairs of vertices are drawn using the bezier arc > approximation technique implemented in Path.arc(). > > > Cheers, > Mike > > > Ted Drain wrote: >> 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 <ted.drain@...> 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 >>> arcapproximationbycubicbezierspline 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 >>> _______________________________________________ >>> Matplotlibdevel mailing list >>> Matplotlibdevel@... >>> https://lists.sourceforge.net/lists/listinfo/matplotlibdevel >> >> Ted Drain Jet Propulsion Laboratory ted.drain@... >> >> >>  >> 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 >> _______________________________________________ >> Matplotlibdevel mailing list >> Matplotlibdevel@... >> https://lists.sourceforge.net/lists/listinfo/matplotlibdevel > > >  > > >  > >  > 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 > > >  > > _______________________________________________ > Matplotlibdevel mailing list > Matplotlibdevel@... > https://lists.sourceforge.net/lists/listinfo/matplotlibdevel  Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA 
From: Michael Droettboom <mdroe@st...>  20071211 20:43:44

I have a working draft of something that may work for this problem on the transforms branch. I am happy to backport this to the trunk, but that will require some effort, as the implementation relies on many of the new geometric utilities on the branch that would also have to be brought over. It may be some time until the branch is ready for production use, but if you are able to use it to experiment with this approach to this specific problem, that would certainly make my life easier, so I don't have to do the backporting work more than once. Attached is a plot comparing the new approach (above) vs. a 750edge polygonal approximation for the ellipses (based directly on James Evans' example). Here's a description of what it does: Ellipses are normally drawn using an approximation that uses eight cubic bezier splines. The error of this approximation is 1.89818e6, according to this unverified source: Lancaster, Don. Approximating a Circle or an Ellipse Using Four Bezier Cubic Splines. http://www.tinaja.com/glib/ellipse4.pdf There is a use case where very large ellipses must be drawn with very high accuracy, and it is too expensive to render the entire ellipse with enough segments (either splines or line segments). Therefore, in the case where either radius of the ellipse is large enough that the error of the spline approximation will be visible (greater than one pixel offset from the ideal), a different technique is used. In that case, only the visible parts of the ellipse are drawn, with each visible arc using a fixed number of spline segments (8). The algorithm proceeds as follows: 1. The points where the ellipse intersects the axes bounding box are located. (This is done be performing an inverse transformation on the axes bbox such that it is relative to the unit circle  this makes the intersection calculation much easier than doing rotated ellipse intersection directly). This uses the "line intersecting a circle" algorithm from: Vince, John. Geometry for Computer Graphics: Formulae, Examples & Proofs. London: SpringerVerlag, 2005. 2. The angles of each of the intersection points are calculated. 3. Proceeding counterclockwise starting in the positive xdirection, each of the visible arcsegments between the pairs of vertices are drawn using the bezier arc approximation technique implemented in Path.arc(). Cheers, Mike Ted Drain wrote: > 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 <ted.drain@...> 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 >> arcapproximationbycubicbezierspline 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 >> _______________________________________________ >> Matplotlibdevel mailing list >> Matplotlibdevel@... >> https://lists.sourceforge.net/lists/listinfo/matplotlibdevel > > Ted Drain Jet Propulsion Laboratory ted.drain@... > > > >  > 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 > _______________________________________________ > Matplotlibdevel mailing list > Matplotlibdevel@... > https://lists.sourceforge.net/lists/listinfo/matplotlibdevel  Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA 
From: Paul Kienzle <pkienzle@ni...>  20071211 19:26:31

On Tue, Dec 11, 2007 at 10:22:12AM 0800, Christopher Barker wrote: > Paul Kienzle wrote: > > or if there are pending wx events. The scheme isn't perfect since wx > > doesn't see all the native events, but it seems to work well enough. > > I'm confused here  what events are missed, and why? What do you mean > by a "native" event? Intermediate mouse positions, for example, seem to be consumed. Also, it doesn't seem to recognize pending resize events. Try an experiment such as resizing examples/pcolor_log.py, with N large enough to make redraws slow to see what I mean (N=200 does it for me). I tried changing the _onSize event handler to use draw_idle rather than draw to improve the resize experience but I shut it off because the drawing area turns black and I couldn't figure out how to set it to the figure background colour. It helped slow graphs a little since I could see what the resulting window would look like, but the black was jarring for quick graphs. Any thoughts on implementing preemptive plotting? This would mean putting tests like the following inside potentially expensive loops: if self.isabort(): break where isabort is a method in class artist which delegates to the canvas: return self.figure.canvas.isabort() if self.figure else False For the wx canvas, isabort() would be something like: wx.Yield() # Allow UI events to be processed return self._draw_idle_requested # abort drawing if UI triggered redraw > > 2) Don't draw bitmap on the screen if the graph isn't shown. Otherwise > > a plot inside of a wx aui notebook bleeds through even if the graph > > notebook is not on top. > > hmmm odd  this does sound right, but shouldn't wx only be redrawing > in a Paint event anyway? I haven't traced through the wx.aui code so I don't know what is going on. I do know that I have problems if I don't check IsWindowShown before blitting the bitmap onto the screen. > > 3) Don't regenerate entire plot for each PaintEvent. Instead, only > > draw the graph if this is the first time the window is exposed, otherwise > > work from the bitmap. > > This is odd to me too  I haven't dug into the wx backend, but it > seems the Paint Event should only trigger a blit of the bitmap to the > screen anyway. It should, but the bitmap may not be initialized when the paint event occurs. This happens when the window is first created (since there is no associated size event) and now when switching aui notebook windows (since I don't render the bitmap if the window isn't shown).  Paul 
From: Christopher Barker <Chris.Barker@no...>  20071211 18:20:36

Paul Kienzle wrote: > 1) implement draw_idle. Rather than using the wx IdleEvent which seemed > to be triggered too often good idea  the wx Idle event is triggered A LOT. I've never found a use for it. > I used a timer which is delayed and possibly > reset if a new draw request comes within a certain time period (5 ms), That's a common trick, and has always worked well for me. > or if there are pending wx events. The scheme isn't perfect since wx > doesn't see all the native events, but it seems to work well enough. I'm confused here  what events are missed, and why? What do you mean by a "native" event? > 2) Don't draw bitmap on the screen if the graph isn't shown. Otherwise > a plot inside of a wx aui notebook bleeds through even if the graph > notebook is not on top. hmmm odd  this does sound right, but shouldn't wx only be redrawing in a Paint event anyway? > 3) Don't regenerate entire plot for each PaintEvent. Instead, only > draw the graph if this is the first time the window is exposed, otherwise > work from the bitmap. This is odd to me too  I haven't dug into the wx backend, but it seems the Paint Event should only trigger a blit of the bitmap to the screen anyway. > I've only tested this for wxagg on the mac. I don't > know if it breaks wx, or if anyone cares about wx anymore. You mean wx, rather then wxAgg? I now some folks have found it useful for remote X sessions  but I don't know how important it is to support that. Chris  Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 5266959 voice 7600 Sand Point Way NE (206) 5266329 fax Seattle, WA 98115 (206) 5266317 main reception Chris.Barker@... 
From: Michael Droettboom <mdroe@st...>  20071211 17:59:46

Thanks. This has already been fixed in SVN, and should make it into the 0.91.2 release shortly. Cheers, Mike Brandon Reno wrote: > I get this error when using canvas.print_svg(): > > In [27]: canvas.print_svg(buffer) >  > <type 'exceptions.NameError'> Traceback (most recent call last) > > Z:\<ipython console> in <module>() > > C:\Python25\Lib\sitepackages\matplotlib\backend_bases.py in > print_svg(self, *ar > gs, **kwargs) > 1124 from backends.backend_svg import FigureCanvasSVG # lazy > import > 1125 svg = self.switch_backends(FigureCanvasSVG) > > 1126 return svg.print_svg(*args, **kwargs) > 1127 > 1128 def print_svgz(self, *args, **kwargs): > > C:\Python25\Lib\sitepackages\matplotlib\backends\backend_svg.py in > print_svg(se > lf, filename, *args, **kwargs) > 463 if is_string_like(filename): > 464 fh_to_close = svgwriter = codecs.open(filename, 'w', > 'utf8' > ) > > 465 elif is_writable_file_like(filename): > 466 svgwriter = codecs.EncodedFile(filename, 'utf8') > 467 fh_to_close = None > > C:\Python25\Lib\sitepackages\matplotlib\cbook.py in > is_writable_file_like(obj) > 215 > 216 def is_writable_file_like(obj): > > 217 return hasattr(filename, 'write') and callable(filename.write) > 218 > 219 def is_scalar(obj): > > <type 'exceptions.NameError'>: global name 'filename' is not defined > > In [28]: canvas > Out[28]: <matplotlib.backends.backend_tkagg.FigureCanvasTkAgg instance > at 0x01CA > EDF0> > > It seems that > def is_writable_file_like(obj): > > should be > def is_writable_file_like(filename): > > >  > >  > 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 > > >  > > _______________________________________________ > Matplotlibdevel mailing list > Matplotlibdevel@... > https://lists.sourceforge.net/lists/listinfo/matplotlibdevel  Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA 
From: Paul Kienzle <pkienzle@ni...>  20071211 17:42:43

Hi, The attached patch has a couple of changes to the wx backend that I want people to test before I commit. 1) implement draw_idle. Rather than using the wx IdleEvent which seemed to be triggered too often I used a timer which is delayed and possibly reset if a new draw request comes within a certain time period (5 ms), or if there are pending wx events. The scheme isn't perfect since wx doesn't see all the native events, but it seems to work well enough. 2) Don't draw bitmap on the screen if the graph isn't shown. Otherwise a plot inside of a wx aui notebook bleeds through even if the graph notebook is not on top. 3) Don't regenerate entire plot for each PaintEvent. Instead, only draw the graph if this is the first time the window is exposed, otherwise work from the bitmap. I've only tested this for wxagg on the mac. I don't know if it breaks wx, or if anyone cares about wx anymore. Let me know if it works for you.  Paul 
From: Brandon Reno <brandonreno@gm...>  20071211 16:13:00

I get this error when using canvas.print_svg(): In [27]: canvas.print_svg(buffer)  <type 'exceptions.NameError'> Traceback (most recent call last) Z:\<ipython console> in <module>() C:\Python25\Lib\sitepackages\matplotlib\backend_bases.py in print_svg(self, *ar gs, **kwargs) 1124 from backends.backend_svg import FigureCanvasSVG # lazy import 1125 svg = self.switch_backends(FigureCanvasSVG) > 1126 return svg.print_svg(*args, **kwargs) 1127 1128 def print_svgz(self, *args, **kwargs): C:\Python25\Lib\sitepackages\matplotlib\backends\backend_svg.py in print_svg(se lf, filename, *args, **kwargs) 463 if is_string_like(filename): 464 fh_to_close = svgwriter = codecs.open(filename, 'w', 'utf8' ) > 465 elif is_writable_file_like(filename): 466 svgwriter = codecs.EncodedFile(filename, 'utf8') 467 fh_to_close = None C:\Python25\Lib\sitepackages\matplotlib\cbook.py in is_writable_file_like(obj) 215 216 def is_writable_file_like(obj): > 217 return hasattr(filename, 'write') and callable(filename.write) 218 219 def is_scalar(obj): <type 'exceptions.NameError'>: global name 'filename' is not defined In [28]: canvas Out[28]: <matplotlib.backends.backend_tkagg.FigureCanvasTkAgg instance at 0x01CA EDF0> It seems that def is_writable_file_like(obj): should be def is_writable_file_like(filename): 