On 2011-01-03 09:51+0100 Arjen Markus wrote: > Hi Alan, > > I just committed the changes: the individual curves > are now drawn both as polylines and as filled curves. > While I do not think it is all that well-defined (some > of the curves are very convoluted, in the colloquial > sense, not the geometrical one), it does give some > interesting results. The deltoid for instance, a > non-intersecting curve, is NOT filled by the wingcc > device.
This may be due to a bug in the underlying Windows library that supports wingcc, and other windows users that use a different windows platform than you might have success with this fill. I get similar bad results (just the outline, no fill for pages 11-13, partial but incorrect fills above that) here for the epsqt and epspng devices. For the qtwidgets device page 11 is okay, but the following pages hang. I have looked through the qt driver and see no issues for large numbers of boundary points for fills. Everything just boils down to a call to drawPolygon (see http://pepper.troll.no/s60prereleases/doc/qpainter.html#drawPolygon) which has a default odd/even filling rule (see discussion below). These issues may be cleared up in some future release of Qt, but if we eventually get perfect results for other devices and still bad results for Qt I will send in a bug report to encourage TrollTech/Nokia to make the fix. > It is for the PostScript output. The next > one in line, a curve like the deltoid but with three > loops in stead of cusps gets partly filled - the > loops are. I don't quite follow this last sentence, but my analysis (see below) is that this figure (page 12) should have everything inside the outer boundary filled. > > I assume you will see the same sort of things with > wine. Actually it is easier for me to test your recent commits on Linux. Before getting started with the psc case, it would be good to review http://en.wikipedia.org/wiki/Point_in_polygon. We use the ray casting algorithm (also known as the even/odd rule especially when dealing with self-intersecting, i.e, complex polygons) to decide what is inside and outside a given polygon so our fill results should correspond to that rule as well. Note that http://pepper.troll.no/s60prereleases/doc/qt.html#FillRule-enum also has a good discussion of the even/odd filling rule versus the non-zero winding number filling rule. The page 2 boundary is simple so everything inside it gets filled and the corresponding psc page 11 results confirm that. The page 3 boundary is our simplest complex polygon case. The inner area AND the outward-pointing loops are all accessible with a straight line that undergoes 1 intersection with an edge of the polygon so all those areas should be filled, and the corresponding page 12 psc results confirm that. Those good page 11 and page 12 fill results indicate to me that the malloc method of dealing with large numbers of boundary points for plfill is working properly which is an important result. For more complex boundaries (corresponding to page 4 and up), we appear to run into logic issues in how plfill decides to fill the polygon. The fourth-page boundary analysis shows the inward-facing loops are accessible with two intersections with a straight line so should be _excluded_ from the fill. The page 13 psc results fill those loops which is an error. The fifth-page boundary analysis shows the outer loops and the innermost areas are accessible with a straight line with an odd number of boundary intersections so the loops and innermost area should be filled which the psc device does for the corresponding page 14 results. But in between the two there is a symmetrical patchwork that should consist of unfilled and filled areas. The page 14 psc results do something similar, but don't select the correct filled and unfilled areas in the patchwork region which is a clear fill error, and also for the right-hand-side of the figure lose the expected symmetry which is also a clear fill error. The pscairo fill results seem exactly equivalent to the psc results so that supports the idea that the fill errors noted above are due to a plfill logic issue rather than a driver issue. Another possible interpretation is something is wrong with my PostScript viewer's rendering of a long self-intersecting boundary polygon that needs to be filled, but that interpretation is shot down by the xcairo and pngcairo results which are viewed completely independently and which show the exact same (bad) fill patterns as the pscairo and psc devices. To sum this up, the bad wingcc and qt results are probably due to external library issues combined with issues in plfill while the bad psc (which depends on no external library) and cairo (which depends on a subset of the GTK+ stack of libraries) results are likely due to issues in plfill. Off list I will send you the compressed results for the psc device (which is 1.6MB despite the compression which is why I am not sending it to the list) so you can see exactly what I am seeing. Once you receive that, please check you are getting the same psc fill results on Windows. 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
