From: Andrew R. <and...@us...> - 2010-12-22 23:15:26
|
Thread moved to plplot-devel as this is becoming a discussion on new developments / improvements. On Wed, Dec 22, 2010 at 02:32:24PM -0800, Alan Irwin wrote: > On 2010-12-22 11:00+0100 Jos? Luis Garc?a Pallero wrote: > > > Hello, > > I think that PLPlot is a great tool. Thanks to the developers for > > their hard work. I'm using PLPlot in order to draw worldmaps with > > coastlines. I'm using plfill, plline and plmap functions and I find > > they very useful. Nevertheless I have some minor problems (I'm using > > PLPlot 5.9.7 compiled by me on a Debian GNU/Linux Sid). > > > > Using plfill I obtain a the message > > > > *** PLPLOT WARNING *** > > plfill: too many points in polygon > > > > using polygons with 1000 vertices. Can I change the maximum number of > > vertices at runtime or must I recompile the library? > > > > I'm using the coastlines from > > http://rimmer.ngdc.noaa.gov/mgg/coast/getcoast.html that are > > downloaded in ascii files with NaN indicators between each piece of > > land. I can see that plfill and plline needs that the x and y arrays > > contains data without "holes" (separators) > > > > I think it would be useful that plfill and plline could work with > > arrays containing some "labels", for example NaN values (0.0/0.0 in > > C), in order to manage several independent polygons or lines as, for > > example, coastlines downloaded from > > http://rimmer.ngdc.noaa.gov/mgg/coast/getcoast.html > > Maybe it would be interesting that plmap or other similar new function > > could load a coastline file, not only the internal of PLPlot. This > > files could fe in the ascii format as from > > http://rimmer.ngdc.noaa.gov/mgg/coast/getcoast.html > > > > Hi Jos?: > > You have brought up a number of interesting points. > > Arjen has already answered you in general terms on the PL_MAXPOLY > question (currently set at a hard limit of 256 in include/plplotP.h). > If you grep through our code for that symbol, you will notice a number > of fixed arrays that are dimensioned with that value. I would welcome > a patch to replace all of those with malloced (and freed) memory so we > could do away with the PL_MAXPOLY limit completely. I definitely agree. > Currently, PLplot has rather limited NaN awareness associated with the > plgriddata functionality (which in turn relies on the csiro libraries > in lib/nn and lib/csa). I would welcome a patch to extend NaN > awareness to plline and plfill (and plgradient). I did some work on this last year (I think?) and plline at least is NaN aware. It used to produce rather odd results. Now any segement where on of the points is a NaN is just ignored. plfill probably isn't well handled. How do you fill in a shape if part of the edges is missing? Better testing and improving is certainly required. It would be nice to see one of the examples illustrate handling of NaN / Inf. > With regard to map data, I would like to repeat what I said last April > to the plplot-devel list. > > <quote> > Is it time to completely update both plmap functionality and example > 19? Yes! As a non-US user it would be nice to have access to good quality local maps. > Currently plmap gives us access to just 4 map outlines which are > stored in data/cglobe.map data/globe.map data/usa.map > data/usaglobe.map. From the "file" command those files are stored in a > binary format that appears to be "Atari 68xxx CPX file (version 03e8)" > format (whatever that is). As far as I know, no software project > other than PLplot stores their map data that way, and obviously users > contemplating using PLplot for their mapping needs require access to > more than just four maps! > > Fortunately, there appears to be substantial effort underway to > provide open-source GIS (geographical information system) software. > See http://opensourcegis.org/ for a list of 247 (!) projects. These > projects obviously require map data to work with, and it appears there > is a lot of it that is free (see http://data.geocomm.com/). > > I think it is time that we take advantage of that free map data rather > than limiting ourselves to just the four map data files that are > currently accessible from PLplot. Ideally the availability of free GIS > data (along with changes to plmap to allow access to those data) > should allow us to replace example 19 to provide examples of some > really high-quality maps that are built directly from free GIS data by > PLplot. For example, it would be nice to provide topographic maps of > my two favorite volcanos, Olympus Mons and Valles Caldera. (The first > is the largest volcano in the solar system, and the second is a > personal favorite of mine because I toured it as a boy, and it is near > the locale of one of my favorite Westerns by Louis L'Amour). But we > don't have to stop with contour maps of volcanos. Please use your > imaginations to think of additional attractive maps that we could > generate as part of a replacement example 19 if/when we gain access to > free GIS data. > </quote> > > One thing I failed to mention explicitly back then is we should use a > free and open-source library to access map data using one API rather > than trying to figure out for ourselves the large number of different > map file formats. > > No action has been taken yet on any of those ideas, but obviously > there is scope for a very large improvement of mapping support for > PLplot so discussion, ideas, and patches would be most welcome. Can I put libgdal on the table as one likely candidate for a mapping library. It provides support for most of the main raster and vector GIS formats. I've not programmed it directly, but it provides most of the file read / write support for GRASS which is one of the most developed free GIS packages. Homepage is http://www.gdal.org/ . Andrew |
From: Maurice L. <mj...@br...> - 2010-12-23 19:01:26
|
On Thursday, December 23, 2010 at 09:28:20 (+0100) José Luis García Pallero writes: > Attached I send a patch for svn plfill() that uses malloc/free in case > of n > PL_MAXPOLY-1. I've used a behavior similar to the function > plP_plfclp() in plfill.c. plP_plfclp tests if the number of point is > greater than PL_MAXPOLY and uses static or dynamic array in > consequence. I've done the same for c_plfill() and c_plfill3(), so for > polygons with small number of vertices no overload is done for the > using of malloc/free. This only introduces two if's sentences: for > test if malloc must be used and for tests if free must be used. And > deletes a if sentence: the check if ( n < PL_MAXPOLY ) in the test for > determining if the last point is the same as the initial in tle > polyline defining the polygon. Have you surveyed the rest of the code base for other places that need changing? I see drivers/xwin.c and src/plbuf.c for sure. Else code will go boom. -- Maurice LeBrun |
From: Arjen M. <arj...@de...> - 2010-12-30 08:05:06
|
Hello, I have finished the work on the source files that use PL_MAXPOLY sized arrays. All now use either the statically defined arrays or allocated arrays if needed. I wonder about one file though: xfig.c. One function in this driver checked the number of points, but it gets passed an array with all the data in there already. Is it that the xfig format does not allow polygons of more than 256 points? (I never use that format and I am unfamiliar with its capabilities and limitations). In any case I have removed the check. I will run the code through the comprehensive test script before committing, but my system does not do anything with xwin.c, tkwin.c or plr.c, so there may be syntax errors in there. Also, none of the examples really use large polygons, so the new parts of the patch will formally go untested. Regards, Arjen On 2010-12-24 09:05, Arjen Markus wrote: > Hi José, > > I examined these files as well: > Some functions would simply return on encountering a large polygon > and other (several in plbuf.c for instance) would just happily > crash the program. > > I have implemented a patch for plbuf.c and plot3d.c, but I have not > tested them yet, so I want to take some more time. I may get around > to do the rest next week, but certainly not this Christmas weekend. > > I will pick up the patches for xwin.c and tkwin.c, so the remaining > files to be patched are: > - plr.c > - xfig.c > - plrender.c > > (plarc.c does not take arbitrary size polygons, merely uses the macro > PL_MAXPOLY, and plline.c splits up a large polyline in pieces). > > There was a nasty little gotcha in c_plfill3: the vertices are > filtered, so that the value of n may be altered. Fixed that in my > applying the patch. > > Regards, > > Arjen > > On 2010-12-24 00:16, José Luis García Pallero wrote: >> Hello again, >> Attached I send patches for trunk/drivers/tkwin.c and trunk/drivers/xwin.c >> I searched in trunk folder from svn repo ad I found this files >> containing PL_MAXPOLY: >> >> trunk/bindings/tk/plr.c >> trunk/drivers/tkwin.c >> trunk/drivers/xfig.c >> trunk/drivers/xwin.c >> trunk/src/plarc.c >> trunk/src/plbuf.c >> trunk/src/plfill.c >> trunk/src/plgradient.c >> trunk/src/plline.c >> trunk/src/plot3d.c >> trunk/utils/plrender.c >> >> but only plfill, plgradient, tkwin and xwin contains exits if the >> number of elements is greater than PL_MAXPOLY (I don't konw in deep >> the code of PLPlot) >> >> Cheers >> > > > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. > The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. > > > > > > ------------------------------------------------------------------------------ > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: José L. G. P. <jgp...@gm...> - 2010-12-30 14:33:32
|
El día 30 de diciembre de 2010 09:04, Arjen Markus <arj...@de...> escribió: > Hello, > > I have finished the work on the source files that use PL_MAXPOLY > sized arrays. All now use either the statically defined arrays or > allocated arrays if needed. > > I wonder about one file though: xfig.c. One function in this driver > checked the number of points, but it gets passed an array with all > the data in there already. Is it that the xfig format does not > allow polygons of more than 256 points? (I never use that format > and I am unfamiliar with its capabilities and limitations). > In any case I have removed the check. > > I will run the code through the comprehensive test script before > committing, but my system does not do anything with xwin.c, tkwin.c > or plr.c, so there may be syntax errors in there. > > Also, none of the examples really use large polygons, so the > new parts of the patch will formally go untested. > > Regards, > > Arjen Hello, Thanks for your job. I hope the new features will be useful to someone as for me. Two minor question: 1. Could my name and email appear in the patched files as a contributor (not in copyright owners list, of course -my contribution was so small-)? In the sent patches for plfill.c, plgradient.c, tkwin.c and xwin.c I put my name and a brief of my contribution, but I don't know if this is the correct way to do that. I would like to put my contribution in my (small) CV. 2. In my patch for plfill.c I changed the comments at the start of plfill() and plfill3() to: // Pattern fills the polygon bounded by the input points. -// If hardware fill is used, a maximum of PL_MAXPOLY-1 vertices is allowed. +// For a number of vertices greater than PL_MAXPOLY - 1, memory is managed via +// malloc/free. Otherwise static arrays of length PL_MAXPOLY are used // The final point is explicitly added if it doesn't match up to the first, // to prevent clipping problems. But in the new code of the svn I don't see that. I think that are informative lines of the new behavior. Don't you think the same? Thanks -- ***************************************** José Luis García Pallero jgp...@gm... (o< / / \ V_/_ Use Debian GNU/Linux and enjoy! ***************************************** |
From: Arjen M. <arj...@de...> - 2011-01-03 08:24:09
|
Hi José, hm, your comments were not in the patch files I used. I have added these comments now. (I also put in your name in the release notes as note 2.46). Just committed the changes. Regards, Arjen On 2010-12-30 15:33, José Luis García Pallero wrote: > El día 30 de diciembre de 2010 09:04, Arjen Markus > <arj...@de...> escribió: >> Hello, >> >> I have finished the work on the source files that use PL_MAXPOLY >> sized arrays. All now use either the statically defined arrays or >> allocated arrays if needed. >> >> I wonder about one file though: xfig.c. One function in this driver >> checked the number of points, but it gets passed an array with all >> the data in there already. Is it that the xfig format does not >> allow polygons of more than 256 points? (I never use that format >> and I am unfamiliar with its capabilities and limitations). >> In any case I have removed the check. >> >> I will run the code through the comprehensive test script before >> committing, but my system does not do anything with xwin.c, tkwin.c >> or plr.c, so there may be syntax errors in there. >> >> Also, none of the examples really use large polygons, so the >> new parts of the patch will formally go untested. >> >> Regards, >> >> Arjen > > Hello, > Thanks for your job. I hope the new features will be useful to someone > as for me. Two minor question: > 1. Could my name and email appear in the patched files as a > contributor (not in copyright owners list, of course -my contribution > was so small-)? In the sent patches for plfill.c, plgradient.c, > tkwin.c and xwin.c I put my name and a brief of my contribution, but I > don't know if this is the correct way to do that. I would like to put > my contribution in my (small) CV. > 2. In my patch for plfill.c I changed the comments at the start of > plfill() and plfill3() to: > > // Pattern fills the polygon bounded by the input points. > -// If hardware fill is used, a maximum of PL_MAXPOLY-1 vertices is allowed. > +// For a number of vertices greater than PL_MAXPOLY - 1, memory is managed via > +// malloc/free. Otherwise static arrays of length PL_MAXPOLY are used > // The final point is explicitly added if it doesn't match up to the first, > // to prevent clipping problems. > > But in the new code of the svn I don't see that. I think that are > informative lines of the new behavior. Don't you think the same? > > Thanks > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2010-12-30 17:58:59
|
On 2010-12-30 15:33+0100 José Luis García Pallero wrote: > El día 30 de diciembre de 2010 09:04, Arjen Markus > <arj...@de...> escribió: >> Hello, >> >> I have finished the work on the source files that use PL_MAXPOLY >> sized arrays. All now use either the statically defined arrays or >> allocated arrays if needed. >> >> I wonder about one file though: xfig.c. One function in this driver >> checked the number of points, but it gets passed an array with all >> the data in there already. Is it that the xfig format does not >> allow polygons of more than 256 points? (I never use that format >> and I am unfamiliar with its capabilities and limitations). >> In any case I have removed the check. >> >> I will run the code through the comprehensive test script before >> committing, but my system does not do anything with xwin.c, tkwin.c >> or plr.c, so there may be syntax errors in there. >> >> Also, none of the examples really use large polygons, so the >> new parts of the patch will formally go untested. >> >> Regards, >> >> Arjen > > Hello, > Thanks for your job. I hope the new features will be useful to someone > as for me. Two minor question: > 1. Could my name and email appear in the patched files as a > contributor (not in copyright owners list, of course -my contribution > was so small-)? In the sent patches for plfill.c, plgradient.c, > tkwin.c and xwin.c I put my name and a brief of my contribution, but I > don't know if this is the correct way to do that. I would like to put > my contribution in my (small) CV. We don't have a formal policy about acknowledging help like yours, and I cannot speak for Arjen, but I am sure your help will be acknowledged somewhere that you can quote in your CV. What I normally do for this case as a matter of courtesy is put an acknowledgement in the commit message which will show up at http://plplot.svn.sourceforge.net/viewvc/plplot. Arjen, if you feel this change is important enough to mention in our release notes, then that could be another possibility for publicly acknowleging the help that José has given us. 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 __________________________ |
From: Arjen M. <arj...@de...> - 2011-01-03 07:36:09
|
Hi Alan, José, I left out José's name in the comments - as we leave such log notices to the SVN system - but I forgot to put his name in the log message when I committed it. I have no objection to putting his name in and as José noticed a missing piece of information I can rectify that omission today. I will also put it into the release notes. Regards, Arjen On 2010-12-30 18:58, Alan W. Irwin wrote: > On 2010-12-30 15:33+0100 José Luis García Pallero wrote: > >> El día 30 de diciembre de 2010 09:04, Arjen Markus >> <arj...@de...> escribió: >>> Hello, >>> >>> I have finished the work on the source files that use PL_MAXPOLY >>> sized arrays. All now use either the statically defined arrays or >>> allocated arrays if needed. >>> >>> I wonder about one file though: xfig.c. One function in this driver >>> checked the number of points, but it gets passed an array with all >>> the data in there already. Is it that the xfig format does not >>> allow polygons of more than 256 points? (I never use that format >>> and I am unfamiliar with its capabilities and limitations). >>> In any case I have removed the check. >>> >>> I will run the code through the comprehensive test script before >>> committing, but my system does not do anything with xwin.c, tkwin.c >>> or plr.c, so there may be syntax errors in there. >>> >>> Also, none of the examples really use large polygons, so the >>> new parts of the patch will formally go untested. >>> >>> Regards, >>> >>> Arjen >> >> Hello, >> Thanks for your job. I hope the new features will be useful to someone >> as for me. Two minor question: >> 1. Could my name and email appear in the patched files as a >> contributor (not in copyright owners list, of course -my contribution >> was so small-)? In the sent patches for plfill.c, plgradient.c, >> tkwin.c and xwin.c I put my name and a brief of my contribution, but I >> don't know if this is the correct way to do that. I would like to put >> my contribution in my (small) CV. > > We don't have a formal policy about acknowledging help like yours, and > I cannot speak for Arjen, but I am sure your help will be acknowledged > somewhere that you can quote in your CV. What I normally do for this > case as a > matter of courtesy is put an acknowledgement in the commit message > which will show up at http://plplot.svn.sourceforge.net/viewvc/plplot. > > > Arjen, if you feel this change is important enough to mention in our > release notes, then that could be another possibility for publicly > acknowleging the help that José has given us. > > 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 > __________________________ > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2010-12-30 19:01:20
|
On 2010-12-30 09:04+0100 Arjen Markus wrote: > Also, none of the examples really use large polygons, so the > new parts of the patch will formally go untested. Hi Arjen: What do you think of the idea of extending example 27 for this purpose by adding pages where plline is replaced by plfill and plgradient? Extending most of the pages of the current example by replacing plline with either plfill or plgradient would test our drivers' ability to handle self-intersecting boundaries for fills and gradients. However, I suspect that none of our drivers could properly handle that case at the moment. If that is correct you could restrict the page extensions just to the current page 2. That boundary does not self-intersect, but it has sufficent points to test the present change. Please give me notice when you do make your commit so I can test the new logic on all devices not accessible to you. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2010-12-31 00:47:36
|
On 2010-12-30 11:01-0800 Alan W. Irwin wrote: > Please give me notice when you do make your commit so I can test the > new logic on all devices not accessible to you. Never mind. plplot-cvs was running late for me, but now I see you have committed the change already. I will give your work (hopefully including your changes to example 27 to do a good test of the new internal implementation for large numbers of boundary points) a try after I have finished with the new swig-generated octave bindings. That will probably be next week. 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 __________________________ |
From: Arjen M. <arj...@de...> - 2011-01-03 08:23:55
|
Hi Alan, that does sound like a good idea. I am curious to see how the drivers handle such things. I can probably do that today. Regards, Arjen On 2010-12-30 20:01, Alan W. Irwin wrote: > On 2010-12-30 09:04+0100 Arjen Markus wrote: > >> Also, none of the examples really use large polygons, so the >> new parts of the patch will formally go untested. > > Hi Arjen: > > What do you think of the idea of extending example 27 for this purpose > by adding pages where plline is replaced by plfill and plgradient? > > Extending most of the pages of the current example by replacing plline > with either plfill or plgradient would test our drivers' ability to > handle self-intersecting boundaries for fills and gradients. However, > I suspect that none of our drivers could properly handle that case at > the moment. If that is correct you could restrict the page extensions > just to the current page 2. That boundary does not self-intersect, > but it has sufficent points to test the present change. > > Please give me notice when you do make your commit so I can test the > new logic on all devices not accessible to you. > > 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 > __________________________ > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Arjen M. <arj...@de...> - 2011-01-03 08:51:29
|
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. 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 assume you will see the same sort of things with wine. I have not tried the gradients yet. That is a next step, later this week. Regards, Arjen On 2010-12-30 20:01, Alan W. Irwin wrote: > On 2010-12-30 09:04+0100 Arjen Markus wrote: > >> Also, none of the examples really use large polygons, so the >> new parts of the patch will formally go untested. > > Hi Arjen: > > What do you think of the idea of extending example 27 for this purpose > by adding pages where plline is replaced by plfill and plgradient? > > Extending most of the pages of the current example by replacing plline > with either plfill or plgradient would test our drivers' ability to > handle self-intersecting boundaries for fills and gradients. However, > I suspect that none of our drivers could properly handle that case at > the moment. If that is correct you could restrict the page extensions > just to the current page 2. That boundary does not self-intersect, > but it has sufficent points to test the present change. > > Please give me notice when you do make your commit so I can test the > new logic on all devices not accessible to you. > > 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 > __________________________ > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2011-01-04 01:58:01
|
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 __________________________ |
From: Alan W. I. <ir...@be...> - 2011-01-04 03:27:33
|
On 2011-01-03 17:57-0800 Alan W. Irwin wrote: > 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. I have just looked at some additional results for -dev svgqt (depends on Qt4); -dev svg (which has no external library dependencies at all); and -dev svgcairo (depends on GTK+ stack). The results for -dev svgqt were bad for page 11 on up following the bad results for the other qt-related devices. There might be something obvious in the qt driver code, but I cannot see it so I ascribe this issue to something wrong for the Qt4 libraries. The svg, svgcairo (and all other cairo devices I have checked), and psc all agree in detail with each other. The consistent fill errors for page 13 and above for all of these constitutes a strong case that there is a fill bug in plfill for complicated boundaries. I also confirmed some of the above results for the npts=240 case for x27c.c, and I suggest you might find it valuable to try that case as well. That value assures all plline, plfill, and plgradient calls are below the PL_MAXPOLY limit of 256. The boundary, although much more irregular for the smaller number of points is also much easier to interpret with the odd/even rule. For this small npts case (which cannot involve the malloc version used when npts > PL_MAXPOLY-1), wxwidgets hangs at page 12 (just like for normal npts), while xcairo gives bad filling results for page 13 and above similar to those that occur for the svg, cairo, and psc devices for the normal npts case. So whatever is wrong with fills for these devices has nothing to do with the malloc versus static array PL_MAXPOLY logic that has been recently introduced. So the good news is the filling errors now shown by example 27 are not a regression. The bad news is this is a long-standing fill bug which we didn't know we had before. :-) 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2011-02-26 01:10:05
|
I have more carefully checked svg, cairo, qt, and xwin results today, and most of my conclusions are different than they were before (sigh). Furthermore, I have made some fundamental changes (revision 11579) in how our qt device driver deals with fills having complex (self-intersecting) boundaries. The first such change was a bug fix for qtwidgets (drawConvexPolygon should never be used for non-simple polygons so I replaced that call with a call to the completely general drawPolygon). The other change was to move from the default Qt::OddEvenFill fill rule to the Qt::WindingFill fill rule. The former appears to have _many_ bugs for complex boundaries. The latter also has bugs, but far fewer than the former. Finally, I changed (revision 11580) -dev xwin to use the (nonzero) WindingRule fill rule rather than the default EvenOddRule fill rule. In general, I now get example 27 fill consistency between all svg, cairo, qt, and xwin devices except for -dev svgqt. For that device alone, revision 11579 changed nothing. If you use "less" to look at the svg file you generate with -dev svgqt, it is clear the evenodd fill rule is being used rather than the requested nonzero fill rule. Ignoring the requested fill rule and using the default instead must be a svg file bug in my version of the Qt4 libraries (4.6.3 from Debian Squeeze). Others with access to newer versions of Qt4 may not get this inconsistent result. Once the above drawConvexPolygon bug was fixed but previous to adopting the Qt::WindingFill fill rule, all qt fill results looked identical for the pngqt, epsqt, and svgqt devices. But pngqt results are just a bitmap so the default Qt::OddEvenFill fill rule must have been implemented within Qt4 itself to create that bitmap. In contrast, epsqt fill results are rendered by gv and svgqt results are rendered using the librsvg library (used, e.g., by "display" or "eog). Furthermore, before I changed the fill rule for -dev xwin its even-odd result was also bad, but consistent with the others listed here. The consistency of these really bad even-odd results means, I think, that the X fill implementation is being used by all drivers other than the bitmapped ones (e.g., pngqt), and for those bitmapped ones, I suspect they must have copied their (bad even-odd fill) code from X. That conclusion is further supported after the change from Qt::OddEvenFill to Qt::WindingFill for the qt devices and EvenOddRule to WindingRule for -dev xwin since now you have consistent results for the qt devices (other than svgqt for the reason discussed above), -dev svg, _and_ all the cairo devices, and the xwin device even though some of those rendered results are not correct. For all those devices, page 14 of example 27, for example, gives consistently wrong results with asymmetric fill results for a symmetrical boundary. In sum, as a work-around to a universally bad implementation of the even-odd fill rule (probably in X) and in individual libraries for bitmapped results, we should, for now, continue to specify the non-zero fill rule (as I have just done for the qt devices and xwin device). Example 27 reveals that that fill rule also has a universally bad implemention, but the bugs are not nearly as severe as in the even-odd fill rule case. N.B. all these comments are specific to X-based platforms such as Linux. It would be a very interesting experiment to run example 27 on non-X platforms such as Windows for all our many different qt and cairo devices. Of course, in that case as well, a distinction must be made between results for bitmapped file devices (where the fill must be internally implemented by either Qt4 or pango/cairo) and non-bitmapped file or interactive devices where the fill is ultimately implemented by the platform's displaying facility that has the same role as X. Finally, because of these fill issues for polygons with self-intersecting boundaries we should probably want to implement our own even-odd _and_ non-zero filling rules by, e.g., partitioning (using the appropriate fill rule) a fill of a self-intersecting polygon into fills of simpler polygons that do not self-intersect. If you google for <partition complex polygon>, http://www.cis.usouthal.edu/~hain/general/Theses/Subramaniam_thesis.pdf is the top result. That master's thesis (University of South Alabama, 2003) is low enough level so even I can understand large parts of it. He even includes his code for implementing such partitions. However, that code has no licensing terms and is partially copied from others at that faculty (presumably with personal permission for him to do so). That means anyone who copies that code would be in violation of Subramaniam's copyright as well as the copyright of others at that faculty. Thus, we should completely ignore his code and instead use Subramaniam's _ideas_ which he has very clearly expressed in the body of the thesis as a pseudo-algorithm for such partitioning. I think this would be a really interesting project for anyone who would like to see better-looking fill results for example 27. Unfortunately, I don't have time to pursue this myself for the forseeable future, but I hope someone else here is inspired to look into this. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2011-02-27 20:43:28
|
On 2010-12-30 09:04+0100 Arjen Markus wrote: > Hello, > > I have finished the work on the source files that use PL_MAXPOLY > sized arrays. All now use either the statically defined arrays or > allocated arrays if needed. > > I wonder about one file though: xfig.c. One function in this driver > checked the number of points, but it gets passed an array with all > the data in there already. Is it that the xfig format does not > allow polygons of more than 256 points? (I never use that format > and I am unfamiliar with its capabilities and limitations). > In any case I have removed the check. > > I will run the code through the comprehensive test script before > committing, but my system does not do anything with xwin.c, tkwin.c > or plr.c, so there may be syntax errors in there. Hi Arjen: Sorry it took me so long to test this. -dev xwin works fine with example 27. However, this morning I discovered that -dev tk hangs with that example. I fixed that issue (revision 11582) by dealing with an obvious PL_MAXPOLY fill issue in bindings/tk/plr.c. Note, there is one more place in that file (look for "Temporary") where there is an obvious remaining PL_MAXPOLY issue. The difficulty there is figuring out the future value of npts from the complicated logic for the LINETO and LINE (which drops through to LINETO) cases so that the required correct size of memory can be allocated. That issue doesn't seem to affect -dev tk for example 27, but nevertheless if somebody could figure out the required memory size (or change the logic so that it is obvious we will always require less than PL_MAXPOLY points for LINETO) that would allow us to finally bring the PL_MAXPOLY issues to rest for bindings/tk/plr.c. Note, there is a similar obvious PL_MAXPOLY LINETO/LINE issue in utils/plrender.c if anybody is still interested in the meta device. 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 __________________________ |
From: Arjen M. <arj...@de...> - 2011-03-07 08:04:29
|
Hi Alan, hm, something to look into, now that I am back from my short holiday. Regards, Arjen On 2011-02-27 21:43, Alan W. Irwin wrote: > On 2010-12-30 09:04+0100 Arjen Markus wrote: > >> Hello, >> >> I have finished the work on the source files that use PL_MAXPOLY >> sized arrays. All now use either the statically defined arrays or >> allocated arrays if needed. >> >> I wonder about one file though: xfig.c. One function in this driver >> checked the number of points, but it gets passed an array with all >> the data in there already. Is it that the xfig format does not >> allow polygons of more than 256 points? (I never use that format >> and I am unfamiliar with its capabilities and limitations). >> In any case I have removed the check. >> >> I will run the code through the comprehensive test script before >> committing, but my system does not do anything with xwin.c, tkwin.c >> or plr.c, so there may be syntax errors in there. > > Hi Arjen: > > Sorry it took me so long to test this. -dev xwin works fine with > example 27. However, this morning I discovered that -dev tk hangs > with that example. I fixed that issue (revision 11582) by dealing with > an obvious PL_MAXPOLY fill issue in bindings/tk/plr.c. > > Note, there is one more place in that file (look for "Temporary") > where there is an obvious remaining PL_MAXPOLY issue. The difficulty > there is figuring out the future value of npts from the complicated > logic for the LINETO and LINE (which drops through to LINETO) cases so > that the required correct size of memory can be allocated. That issue > doesn't seem to affect -dev tk for example 27, but nevertheless if > somebody could figure out the required memory size (or change the > logic so that it is obvious we will always require less than > PL_MAXPOLY points for LINETO) that would allow us to finally bring the > PL_MAXPOLY issues to rest for bindings/tk/plr.c. > > Note, there is a similar obvious PL_MAXPOLY LINETO/LINE issue in > utils/plrender.c if anybody is still interested in the meta device. > > 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 > __________________________ > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2011-03-01 19:09:37
|
On 2011-02-25 17:09-0800 Alan W. Irwin wrote: > [...]The > consistency of these really bad even-odd results means, I think, that > the X fill implementation is being used by all drivers other than the > bitmapped ones (e.g., pngqt), and for those bitmapped ones, I suspect > they must have copied their (bad even-odd fill) code from X. > > [...] For all those devices [using the winding number fill rule], > page 14 of example 27, for example, gives consistently wrong results > with asymmetric fill results for a symmetrical boundary. I have followed up with both Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615491) and X (https://bugs.freedesktop.org/show_bug.cgi?id=34877) bug reports about the fill issue in X (which I believe is the origin of all the other Linux platform fill problems we have for the self-intersecting boundaries of example 27). In light of a warning from one Debian developer that the X fill code was old and untouched for years so there would probably be reluctance from the X developers to learn enough about it to fix it, then the alternate course of developing our own solution for filling self-intersecting boundaries based on the Master's thesis referred to below gains some urgency. Does anybody here want to have a go at that? > Finally, because of these fill issues for polygons with > self-intersecting boundaries we should probably want to implement our > own even-odd _and_ non-zero filling rules by, e.g., partitioning > (using the appropriate fill rule) a fill of a self-intersecting > polygon into fills of simpler polygons that do not self-intersect. If > you google for <partition complex polygon>, > http://www.cis.usouthal.edu/~hain/general/Theses/Subramaniam_thesis.pdf > is the top result. That master's thesis (University of South Alabama, > 2003) is low enough level so even I can understand large parts of it. > He even includes his code for implementing > such partitions. However, that code has no licensing terms and is > partially copied from others at that faculty (presumably with personal > permission for him to do so). That means anyone who copies that code > would be in violation of Subramaniam's copyright as well as the > copyright of others at that faculty. Thus, we should completely > ignore his code and instead use Subramaniam's _ideas_ which he has very > clearly expressed in the body of the thesis as a pseudo-algorithm for > such partitioning. > > I think this would be a really interesting project for anyone who > would like to see better-looking fill results for example 27. > Unfortunately, I don't have time to pursue this myself for the > forseeable future, but I hope someone else here is inspired to look > into this. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2011-03-02 21:37:33
|
As of revision 11588, the -eofill command-line option has been implemented. It is currently honored by the xwin, svg, qt, and cairo device drivers. Normally all the devices associated with the above device drivers use the nonzero fill rule for fills of self-intersecting boundaries like you get for example 27. However, for these devices if you use the -eofill option, e.g., examples/c/x27c -dev xcairo -eofill then plsc->dev_eofill is set to 1, and the various device drivers above use the the evenodd fill rule for self-intersecting boundaries like occur, e.g., in example 27. For the wingcc device, I believe you need to call the SetPolyFillMode Function (http://msdn.microsoft.com/en-us/library/dd145080.aspx) to set up either the oddeven (ALTERNATE) or nonzero (WINDING) fill modes for self-intersecting boundaries. Could somebody with access to windows implement one of the two possible calls of SetPolyFillMode depending on the value of pls->dev_eofill (set by the -eofill option)? If Windows uses the same fill algorithm as X (which is entirely possible since X has been around for years and anybody can use that MIT-licensed code for virtually anything they like), then that ALTERNATE (evenodd) fill mode (currently the default when SetPolyFillMode is not called) would show terrible-looking results (no fills at all for pages 11-13, many missing fill regions and some regions filled that shouldn't be for the subsequent pages) for the fill pages of example 27. For the conditions stated, the WINDING fill mode would show much better looking results (good results for pages 11-13, modest but incorrect results [asymmetries] for pages 14 and higher). 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2011-03-03 01:10:29
|
On 2011-03-02 13:37-0800 Alan W. Irwin wrote: > For the wingcc device, I believe you need to call the SetPolyFillMode > Function (http://msdn.microsoft.com/en-us/library/dd145080.aspx) to > set up either the oddeven (ALTERNATE) or nonzero (WINDING) fill modes > for self-intersecting boundaries. Could somebody with access to > windows implement one of the two possible calls of SetPolyFillMode > depending on the value of pls->dev_eofill (set by the -eofill option)? hmm. I just remembered I have access to a Windows platform myself (wine), and this change (revision 11589) worked well there. For the "MSYS Makefiles" generator the test was straightforward (after running cmake with the -DBUILD_TEST=ON option): make -j4 wingcc make x27c examples/c/x27c.exe -dev wingcc -eofill examples/c/x27c.exe -dev wingcc The -eofill run-time option (or dropping that option) with -dev wingcc now gives the same results for example 27 under wine as -dev xwin under Linux. A probably explanation is the wine display must ultimately be translated into an X display (assuming the wine implementation of Windows does not do its own fill rules). A more interesting experiment would be to run -dev wingcc under Microsoft Windows with and without the -eofill option for example 27 to see what the Microsoft fill rules look like. Therefore, could somebody please do these two Microsoft Windows platform tests and report back what is seen for the two different fill rules? In particular do you get the same results as the screenshot attachments located at https://bugs.freedesktop.org/show_bug.cgi?id=34877? 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2011-03-03 20:41:27
|
As of revision 11591 I have made the ps, psttf, and pdf device drivers honour pls->dev_eofill. All of those now produce consistent results with -dev xwin. That is, the -eofill results (even-odd filling rule used in the devices) have lots of rendering errors that are consistent with the -dev xwin results while if that option is dropped (so the nonzero winding number filling rule is used in the various devices), then the rendering errors are much less severe but still consistent with -dev xwin. This is the same consistent filling error result obtained for all other maintained devices as well. The only exceptions that I am aware of are svgqt (caused by a bug in Qt4 so fill-rule instructions to Qt4 are ignored and the default even-odd fill rule always used in that case), aqt, and wxwidgets. I have been unable to figure out how to specify the two possible fill rules for aqt and wxwidgets so I leave those changes to Hazen and Werner. Please test -eofill (and not) for example 27 for both the Apple platform and the Microsoft Windows platform and report back results. Such tests will show whether there exists any platform that does correct filling in either the even-odd or nonzero winding number fill rule cases for self-intersecting boundaries. The results may also support the hypothesis that every platform has consistently copied bad fill code from a common (X?) source, and that would be an interesting result as well. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2011-03-03 23:10:10
|
On 2011-03-03 12:41-0800 Alan W. Irwin wrote: > [...]I have been unable to > figure out how to specify the two possible fill rules for aqt and > wxwidgets so I leave those changes to Hazen and Werner. Hi Werner: Actually I did figure out how to specify both fill rules for the wxGC mode of wxwidgets (revision 11592), and for that mode I now get the same consistent fill errors with example 27 (with -eofill or not) as with -dev xwin and the other devices. As of revision 11593 I did something similar with the basic mode of wxwidgets, but despite following the wxwidgets basic mode documentation, the result builds and also executes without obvious errors at run time but ignores the directive and always uses the even-odd filling rule (i.e., is consistent with the -dev xwin -eofill result for example 27). I don't think there is anything more to do there than wait for the wxwidgets fix so that wxWINDING_RULE is not ignored in the DrawPolygon call. I could not find any fill-rule documentation for agg so did nothing for that mode of the wxwidgets device. So I leave fixing up that agg mode of the wxwidgets device driver to you and fixing up the aqt device driver to Hazen such that the two possible fill rules are honored depending on pls->dev_eofill (i.e, whether or not the -eofill PLplot option is used). 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2011-03-04 21:30:14
|
On 2011-03-03 12:41-0800 Alan W. Irwin wrote: > Please test -eofill (and not) for example 27 for both the Apple > platform and the Microsoft Windows platform and report back results. > Such tests will show whether there exists any platform that does > correct filling in either the even-odd or nonzero winding number fill > rule cases for self-intersecting boundaries. The results may also > support the hypothesis that every platform has consistently copied bad > fill code from a common (X?) source, and that would be an interesting > result as well. As of revision 11594 I have sorted out all the Linux fill issues (with and without -eofill) for example 27 for both python and C. The results with -eofill are not only correct but also beautiful. The results without -eofill are also correct (symmetrical). The issue was an incorrect windings number that so complicated the boundary (with many duplicate boundaries) that correct fills were being generated that looked incorrect for the -eofill case. The incorrect windings also caused a large last boundary segment that introduced asymmetries into the case without -eofill. My thanks to M Joonas Pihlaja of the cairo team who gave me a strong hint that helped me solve this windings issue. Now that the issue has been fixed, a nice side benefit is NPTS can be reduced by a factor of 10 without compromising the smooth-looking results. Please propagate these example 27 changes to all other languages. Also, please try out example 27 with and without -eofill for both Mac and Windows platforms to make sure fills on non-Linux platforms are also working correctly for self-intersecting boundaries. Assuming that is verified the urgency of figuring out the Master's thesis on partitioning polygons with self-intersecting boundaries is not nearly as urgent. However, at some date in the distant future I think we may need to implement that logic for the case where we are dealing with filling a _clipped_ polygon with self-intersecting boundaries. 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 __________________________ |
From: Arjen M. <arj...@de...> - 2011-03-08 12:10:17
|
Hi Alan, I have tested example 27 on Windows and it is looking very nice now. With and without -eofill. The Tcl version is still a bit awkward - it produces a PostScript file that is ten times too large - but it seems fine on the screen. Regards, Arjen On 2011-03-04 22:30, Alan W. Irwin wrote: > On 2011-03-03 12:41-0800 Alan W. Irwin wrote: > >> Please test -eofill (and not) for example 27 for both the Apple >> platform and the Microsoft Windows platform and report back results. >> Such tests will show whether there exists any platform that does >> correct filling in either the even-odd or nonzero winding number fill >> rule cases for self-intersecting boundaries. The results may also >> support the hypothesis that every platform has consistently copied bad >> fill code from a common (X?) source, and that would be an interesting >> result as well. > > As of revision 11594 I have sorted out all the Linux fill issues (with > and without -eofill) for example 27 for both python and C. The > results with -eofill are not only correct but also beautiful. The > results without -eofill are also correct (symmetrical). > > The issue was an incorrect windings number that so complicated the > boundary (with many duplicate boundaries) that correct fills were > being generated that looked incorrect for the -eofill case. The > incorrect windings also caused a large last boundary segment that > introduced asymmetries into the case without -eofill. My thanks to M > Joonas Pihlaja of the cairo team who gave me a strong hint that helped > me solve this windings issue. > > Now that the issue has been fixed, a nice side benefit is NPTS can be > reduced by a factor of 10 without compromising the smooth-looking > results. > > Please propagate these example 27 changes to all other languages. > > Also, please try out example 27 with and without -eofill for both Mac > and Windows platforms to make sure fills on non-Linux platforms are > also working correctly for self-intersecting boundaries. Assuming > that is verified the urgency of figuring out the Master's thesis on > partitioning polygons with self-intersecting boundaries is not nearly > as urgent. However, at some date in the distant future I think we may > need to implement that logic for the case where we are dealing with > filling a _clipped_ polygon with self-intersecting boundaries. > > 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 > __________________________ > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2011-03-08 18:07:46
|
On 2011-03-08 13:09+0100 Arjen Markus wrote: > Hi Alan, > > I have tested example 27 on Windows and it is looking very nice now. > With and without -eofill. > > The Tcl version is still a bit awkward - it produces a PostScript > file that is ten times too large - but it seems fine on the screen. Hi Arjen: I fixed (revision 11610) the remaining minor issues that were causing incompatibility: NPNTS had to be reduced by a factor of 10 (which speeds up the example by the same factor); xmin, xmax, ymin, and ymax had to be adjusted, and also an off-by-one error in $n had to be solved. ==> tcl Missing examples : Differing postscript output : Missing stdout : Differing stdout : Now ain't that a pretty sight. :-) 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 __________________________ |
From: Arjen M. <arj...@de...> - 2011-03-09 07:32:27
|
Hi Alan, On 2011-03-08 19:07, Alan W. Irwin wrote: > On 2011-03-08 13:09+0100 Arjen Markus wrote: > >> Hi Alan, >> >> I have tested example 27 on Windows and it is looking very nice now. >> With and without -eofill. >> >> The Tcl version is still a bit awkward - it produces a PostScript >> file that is ten times too large - but it seems fine on the screen. > > Hi Arjen: > > I fixed (revision 11610) the remaining minor issues that were causing > incompatibility: NPNTS had to be reduced by a factor of 10 (which > speeds up the example by the same factor); xmin, xmax, ymin, and ymax > had to be adjusted, and also an off-by-one error in $n had to be solved. > Great :) > ==> > > tcl > Missing examples : > Differing postscript output : > Missing stdout : > Differing stdout : > > Now ain't that a pretty sight. :-) > Even greater :D Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |