On 2010-12-22 22:05-0700 Maurice LeBrun wrote: > On Wednesday, December 22, 2010 at 23:15:12 (+0000) Andrew Ross writes: > > > > 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? > > > > > [snip] > > > > 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. > > A cautionary note: PL_MAXPOLY impacts a fair amount of code. Also there are > heap-vs-stack performance implications -- e.g. directly moving from a fixed > allocation to a malloc/free each time plfill() is called could suck for the > many small-n-vertices polygon case. Using per-stream polyline buffers is > better but more convoluted. The short term solution is definitely just > recompile with a higher limit.
Thanks for reminding us of these good points. Also, PL_MAXPOLY does not constrain the number of points making up a line with plline since the approach appears to be to break up long lines into segments that are smaller than PL_MAXPOLY. So the issue is only how to modify the plfill and plgradient cases so there is no fixed number of points limitation. Which reminds me I am still not done with my alternative plfill and plgradient approaches which do break up the filled area into logical pieces depending on how the polygon clipping path intersects with the edges of the filled area. So perhaps the best thing to do at the moment is to put further discussion and development on hold until I can finish up that work (quite a few months from now the way other things are going). But as part of that work I do plan to remove the number of points limitation. 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
