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
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
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
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
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
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
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
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.
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)
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
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,
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.
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
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
El día 30 de diciembre de 2010 09:04, Arjen Markus
arjen.mar...@deltares.nl 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.
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
arjen.mar...@deltares.nl 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
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
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
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
Hi José,
at a first glance this patch (and the one for plgradient) seems okay.
Only one tiny thing: I am not sure free() can be used with a NULL
argument. So, I'd say you have to guard against that. (If no one
picks this up, I will)
Regards,
Arjen
On 2010-12-23 09:55, José Luis García Pallero
El día 23 de diciembre de 2010 13:35, Arjen Markus
arjen.mar...@deltares.nl escribió:
Hi José,
at a first glance this patch (and the one for plgradient) seems okay.
Only one tiny thing: I am not sure free() can be used with a NULL
argument. So, I'd say you have to guard against that. (If no
Hi José,
ah, well, personally I detest this type of magic, it means I
have to remember all these little facts, but it means that
your patch ought to be applicable as is. I will see to it.
Regards,
Arjen
On 2010-12-23 13:39, José Luis García Pallero wrote:
El día 23 de diciembre de 2010 13:35,
El día 23 de diciembre de 2010 13:41, Arjen Markus
arjen.mar...@deltares.nl escribió:
Hi José,
ah, well, personally I detest this type of magic, it means I
have to remember all these little facts, but it means that
your patch ought to be applicable as is. I will see to it.
Regards,
Arjen
Hi José,
stopping the program in such dramatic circumstances may be the
best option. We have had some discussion recently about the
best policy, but I am what consensus was reached. I suggest
right now we go ahead with your patch and see what corrections
are needed later (running out of memory
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
Hi Arjen, José, and Maurice:
(I am explicitly addressing Maurice as well since he may know the
origin of the free_mem macro that I discuss below.)
First, I would like to thank José for his plfill and plgradient
patches, and I am glad Arjen is going to apply them. That will make
my further
On Dec 22, 2010, at 9:05 PM, Maurice LeBrun wrote:
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
Attached I send the (I think) definitive patches for plfill.c and
plgradient.c. I've used the plexit() function if any malloc() fails
for consistency with the rest of the code. I'll try to find the other
sources in wich PL_MAXPOLY appears.
Sorry for the previous wrong patches.
--
On Wednesday, December 22, 2010 at 23:15:12 (+) 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
29 matches
Mail list logo
