Re: [Plplot-devel] Possible bug fix for shade_triangle in the clipped case

 Re: [Plplot-devel] Possible bug fix for shade_triangle in the clipped case From: Alan W. Irwin - 2004-05-01 16:33:39 ```On 2004-04-11 22:37-0700 Alan W. Irwin wrote: > One of my research plots tripped over a bug in shade_triangle. When the > repeated calls to plP_clip_poly end up with n=0 (i.e., all triangle points > outside the clipping range), then uninitialized memory was used to define > u[0] and v[0] and the invocation of plP_fill(u, v, n+1); (where n=0) leads to > some peculiar postscript plots with a huge bounding box and presumably > (although I couldn't spot them by eye) single dots painted on the edge of > the box. > > My research plotting problem was fixed if shade_triangle > skips everything unless n > 0. I have committed that result. > > There is also corresponding clipping logic in c_plfill3, but there we call > plP_plfclp which simply returns without action if the number of points is > less than 3 so no fix is required in that case. > > Joao: I don't really understand the logic of what happens when plP_fill(u, > v, n+1); is invoked with n = 1 or 2 from shade_triangle. Should the change > I have committed for shade_triangle be changed to n > 2 to avoid any bad > situations with plP_fill? It turns out I asked the wrong question here since plP_fill(u, v, n+1); is never invoked with n = 1 or 2 from shade_triangle. The reason is that n=plP_clip_poly(n, ...), must always return 0 or n, or an integer larger than n. Thus, in shade_triangle where the initial value of n is 3, before the n=plP_clip_poly(n, ...) calls, my subsequent test for n>0 after those calls is sufficient because it assures plP_fill(u, v, n+1); is always called with n >=3. Thus, that test for n>0 that I put in to solve the particular bug I found is sufficient, and no further changes of the shade_triangle code should be necessary. "Possible" should now be dropped from the subject line. :-) Alan __________________________ Alan W. Irwin email: irwin@... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ```

 [Plplot-devel] Possible bug fix for shade_triangle in the clipped case From: Alan W. Irwin - 2004-04-12 05:43:33 ```One of my research plots tripped over a bug in shade_triangle. When the repeated calls to plP_clip_poly end up with n=0 (i.e., all triangle points outside the clipping range), then uninitialized memory was used to define u[0] and v[0] and the invocation of plP_fill(u, v, n+1); (where n=0) leads to some peculiar postscript plots with a huge bounding box and presumably (although I couldn't spot them by eye) single dots painted on the edge of the box. My research plotting problem was fixed if shade_triangle skips everything unless n > 0. I have committed that result. There is also corresponding clipping logic in c_plfill3, but there we call plP_plfclp which simply returns without action if the number of points is less than 3 so no fix is required in that case. Joao: I don't really understand the logic of what happens when plP_fill(u, v, n+1); is invoked with n = 1 or 2 from shade_triangle. Should the change I have committed for shade_triangle be changed to n > 2 to avoid any bad situations with plP_fill? Alan __________________________ Alan W. Irwin email: irwin@... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ```
 Re: [Plplot-devel] Possible bug fix for shade_triangle in the clipped case From: Alan W. Irwin - 2004-05-01 16:33:39 ```On 2004-04-11 22:37-0700 Alan W. Irwin wrote: > One of my research plots tripped over a bug in shade_triangle. When the > repeated calls to plP_clip_poly end up with n=0 (i.e., all triangle points > outside the clipping range), then uninitialized memory was used to define > u[0] and v[0] and the invocation of plP_fill(u, v, n+1); (where n=0) leads to > some peculiar postscript plots with a huge bounding box and presumably > (although I couldn't spot them by eye) single dots painted on the edge of > the box. > > My research plotting problem was fixed if shade_triangle > skips everything unless n > 0. I have committed that result. > > There is also corresponding clipping logic in c_plfill3, but there we call > plP_plfclp which simply returns without action if the number of points is > less than 3 so no fix is required in that case. > > Joao: I don't really understand the logic of what happens when plP_fill(u, > v, n+1); is invoked with n = 1 or 2 from shade_triangle. Should the change > I have committed for shade_triangle be changed to n > 2 to avoid any bad > situations with plP_fill? It turns out I asked the wrong question here since plP_fill(u, v, n+1); is never invoked with n = 1 or 2 from shade_triangle. The reason is that n=plP_clip_poly(n, ...), must always return 0 or n, or an integer larger than n. Thus, in shade_triangle where the initial value of n is 3, before the n=plP_clip_poly(n, ...) calls, my subsequent test for n>0 after those calls is sufficient because it assures plP_fill(u, v, n+1); is always called with n >=3. Thus, that test for n>0 that I put in to solve the particular bug I found is sufficient, and no further changes of the shade_triangle code should be necessary. "Possible" should now be dropped from the subject line. :-) Alan __________________________ Alan W. Irwin email: irwin@... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ```