Hi, As title, When extremely zooming in by 'Zoom to Rectangle' navigation button, there will strange plot. A script is attached and two strange plots are attached. The problem can be easily reproduced by selecting a tiny(Please refer to xaxis on attached strange plots for a sense) rectangle area which contains a vertexes. Does anyone notice the problem and has something to say about it? Is there some limitation in zoom operation? Thank you for your opinion and guidance. Regards -- sunzen <<freedom & enjoyment>>
I'm not able to reproduce this bug. What version of matplotlib are you using and which backend? Cheers, Mike Sunzen Wang wrote: > Hi, > > As title, When extremely zooming in by 'Zoom to Rectangle' navigation > button, there will strange plot. A script is attached and two strange > plots are attached. The problem can be easily reproduced by selecting > a tiny(Please refer to xaxis on attached strange plots for a sense) > rectangle area which contains a vertexes. > Does anyone notice the problem and has something to say about it? Is > there some limitation in zoom operation? > > Thank you for your opinion and guidance. > > Regards > -- > sunzen > <<freedom & enjoyment>> > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save 100ドル. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
Oh, a pity. While it's true that it is easily reproduced on my system and also my users'. On my system, matplotlib is 0.90.1, and gtkagg backend is used. Thank you for your attention. Regards On Fri, Apr 25, 2008 at 8:15 PM, Michael Droettboom <md...@st...> wrote: > I'm not able to reproduce this bug. What version of matplotlib are you > using and which backend? > > Cheers, > Mike > -- > Michael Droettboom > Science Software Branch > Operations and Engineering Division > Space Telescope Science Institute > Operated by AURA for NASA > > -- sunzen <<freedom & enjoyment>>
Hi Sunzen, I also get similar results as you. - always have 'extremely zoomed' means I pick a corner of your staircase, and zoom in on the corner multiple times, each time no bigger than the cross hairs of the cursor. If I don't get the blocked out triangles I get the data changing direction i.e. if looking at | --- I might see --- or |__ or __| | I've seen similar results with other graphic toolset (not python based) I feel it something to do with zooming in beyond the resolution of the underlying system (no evidence of this) Steve Sunzen Wang wrote: > Oh, a pity. > While it's true that it is easily reproduced on my system and also my > users'. > On my system, matplotlib is 0.90.1, and gtkagg backend is used. > > Thank you for your attention. > > Regards > On Fri, Apr 25, 2008 at 8:15 PM, Michael Droettboom <md...@st... > <mailto:md...@st...>> wrote: > > I'm not able to reproduce this bug. What version of matplotlib > are you using and which backend? > > Cheers, > Mike > -- > Michael Droettboom > Science Software Branch > Operations and Engineering Division > Space Telescope Science Institute > Operated by AURA for NASA > > > -- > sunzen > <<freedom & enjoyment>> > > ------------------------------------------------------------------------
Hi Stephen, On Mon, Apr 28, 2008 at 1:57 PM, Stephen George <ste...@op...> wrote: > Hi Sunzen, > > I also get similar results as you. - always have Thank you for your trying. > > 'extremely zoomed' means I pick a corner of your staircase, and zoom in > on the corner multiple times, each time no bigger than the cross hairs > of the cursor. > > If I don't get the blocked out triangles I get the data changing direction > > i.e. if looking at > > | > --- > > I might see > --- or |__ or __| > | Good description! > > I've seen similar results with other graphic toolset (not python based) > Oh. What kind of other graphic toolset? > I feel it something to do with zooming in beyond the resolution of the > underlying system (no evidence of this) > I have no idea of it. Could some masters say something about it? -- sunzen <<freedom & enjoyment>>
On Mon, Apr 28, 2008 at 8:21 PM, Sunzen Wang <su...@gm...> wrote: > > I feel it something to do with zooming in beyond the resolution of the > > underlying system (no evidence of this) > > > I have no idea of it. Could some masters say something about it? This is an old, long standing bug. It definitely existed in the agg backends in older versions of matplotlib, but I wasn't able to reproduce it when I tried on the maintenance branch or the trunk, so I don't know if some of Michaels changes have fixed it. It has been a while since I looked at it, but the basic problem is that as you zoom repeatedly, the logical canvas size (outside the viewport) becomes so large that some of the data is overflowing some of aggs datastructures. Michaels has done some work to cull points outside the viewport at the backend level, so please see if you can reproduce this on the svn trunk. JDH
I was able to reproduce it on 0.90.1 and 0.91.2, but not SVN trunk. This could be because the affine transformation that does the zooming in now happening within the Agg backend rather than at the Python level -- i.e. there are fewer opportunities for floating-point underflow and the like. Of course, SVN trunk is not yet considered stable enough for general usage, unfortunately. However, it may be too difficult to fix this in earlier versions, because I suspect the fix would involve a fairly significant overhaul of where these transformations take place. Cheers, Mike John Hunter wrote: > On Mon, Apr 28, 2008 at 8:21 PM, Sunzen Wang <su...@gm...> wrote: > > >> > I feel it something to do with zooming in beyond the resolution of the >> > underlying system (no evidence of this) >> > >> I have no idea of it. Could some masters say something about it? >> > > This is an old, long standing bug. It definitely existed in the agg > backends in older versions of matplotlib, but I wasn't able to > reproduce it when I tried on the maintenance branch or the trunk, so I > don't know if some of Michaels changes have fixed it. It has been a > while since I looked at it, but the basic problem is that as you zoom > repeatedly, the logical canvas size (outside the viewport) becomes so > large that some of the data is overflowing some of aggs > datastructures. Michaels has done some work to cull points outside > the viewport at the backend level, so please see if you can reproduce > this on the svn trunk. > > JDH > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save 100ドル. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
On Tue, Apr 29, 2008 at 7:45 AM, Michael Droettboom <md...@st...> wrote: > I was able to reproduce it on 0.90.1 and 0.91.2, but not SVN trunk. This > could be because the affine transformation that does the zooming in now > happening within the Agg backend rather than at the Python level -- i.e. > there are fewer opportunities for floating-point underflow and the like. Of > course, SVN trunk is not yet considered stable enough for general usage, > unfortunately. However, it may be too difficult to fix this in earlier > versions, because I suspect the fix would involve a fairly significant > overhaul of where these transformations take place. Fixing this on the maintenance branch is definitely not a priority. We've lived with this one for years and it only arises in extreme zooming. Since it is fixed on the trunk, we can be happy for that. Thanks, JDH