Hi Phil: It was good to hear from you again.
On 2016-09-12 03:06+0100 Phil Rosenberg wrote: > Hi All > It's been a while. Sorry for my lack of activity over the summer. I took quite a long break from PLplot this summer as well. So no worries about that. > > I've just picked up some Plplot items again on my to do list, starting > with the fill problem that I reported a rather long time ago. > > I have sorted a minimal example to reproduce the bug - see attached. > it turns out that a number of things need to come together to cause > this problem. The example is based on example 12 and draws a very > small trapezium just off the bottom left corner of the plot. however > what happens instead is that the whole plot is filled. The way this > works is that a test point is selected to the right of the fill shape > and Plplot examines if a line between this point and the bottom left > corner intersects the polygon segments to test if the bottom left > corner is in the polygon. When the test is performed segments that are > close to parallel (based on a ~2 pixel fuzziness) are flagged and in > the end treat as a non-intersection. Also if the intersection is close > to the end of a line (again 2 pixels is the limit) then the > intersection is flagged as too close. > > In this special case the three short sides are all approximately 2 > Plplot internal units long which fools the intersection test into > thinking they are close to parallel to the test line. See > notpointinpolygon() and notcrossed() functions. These three lines are > therefore treated as non-intersectionctions even though the test line > does intersect one of them. Finally the fourth section is just long > enough and the location is just correct that the test line intersects > it more than 2 pixels from each end. The result is that the point in > polygon test sees 1 intersection instead of two and incorrectly > concludes that the bottom left corner is inside the polygon. > > The final item that causes the bug to manifest is that the polygon is > entirely outside of the plot area so no segments are drawable. The > test that Plplot performs to see if the whole plot needs filling is > that the bottom left corner is inside the fill polygon and all > segments are outside the plot area. Hence the incorrect full fill. Thanks very much for providing this example and a thorough explanation of what is going wrong on your particular platform, but I cannot reproduce the problem here on Linux (gcc version 4.9.2 with CFLAGS="-O3" which I presume makes some rounding go just the wrong way so this fill bug is not exposed). Instead of the coloured fill of the whole plot you describe, all I get is a labelled blank plot (which is I believe the result you desired). Assuming you confirm that good result with gcc and CFLAGS="-O3", can you modify your example so it triggers the fill bug(s) for all compiler and optimization level cases? @Arjen: I am interested whether gcc on Cygwin for this current example triggers the bug or not. > > I'm still of the opinion that the notcrossed function should not use > the 2 pixel fuzziness. At this point in the drawing we are dealing in > integer pixels and we need only an epsilon test I think. I think the > best fix is to change this. There are some sticking plaster solutions > that would hide the problem but not really fix it in my opinion. I > would really like to change the notcrossed function unless anyone has > some really strong objections? My opinion is this is an extraordinarily tricky topic where all the currently active fill code (i.e., the part of the code not currently removed by the C preprocessor) needs to be completely reviewed and potentially rewritten. Also, I think the fuzziness logic (with all bugs fixed in that code) should stay just in the interests of providing some tolerance for numerical rounding errors. For example, even the article <https://en.wikipedia.org/wiki/Point_in_polygon> talks of providing some numerical tolerance. Note also, such tolerance is certainly required for the integer case since minute rounding errors in the floating point calculations that decide, for example, whether a point is inside or outside a polygon can shift integer results around by +/- 1. I have a topic branch where I have already taken some substantial steps along the above ideas (including at least one bug fix in our current fuzzy logic in notcrossed). I temporarily halted work on that topic some time ago, but assuming you can provide a test example that triggers fill bugs regardless of compiler or optimization level, I plan to take up that topic again where the first order of business will be to compare (using imagemagick image differences) updated fill algorithm results versus 5.11.1 results for all our standard examples that use fill in some way. (That test should turn up any unusual fill artifacts in our examples that are generated by bugs in the original or revised fill algorithm, and once that test is implemented it should be done for any fill change from now on.) In addition, of course, I will look carefully at your example to make sure the revised fill algorithm produces the correct result for it. Assuming you are able to provide the requested example which triggers the fill bug regardless of rounding issues, and the above plan meets with your approval, I would plan to start working on this topic again just after the current release is out the door. Note also there are still a number of relatively small issues I would like to address for this release, but because of the break I mentioned above, I made little progress on those this summer so that release deadline is still indefinite and at least a month or two away. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
