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 t
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 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
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
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 nonz
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 wxwidg
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-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. C
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 fo
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 t
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
> che
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
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 librarie
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 g
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
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, Ar
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 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 t
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 (hope
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 15:33+0100 José Luis García Pallero wrote:
> El día 30 de diciembre de 2010 09:04, Arjen Markus
> 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 ne
El día 30 de diciembre de 2010 09:04, Arjen Markus
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 t
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
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
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
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 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 smal
On Thursday, December 23, 2010 at 11:00:26 (-0800) Alan W. Irwin writes:
> Maurice, do you know the origins of the free_mem macro in
> include/plplotP.h? That does deal with the NULL pointer case for
> frees, but it also sets the pointer to NULL after every free so I
> think this macro was mea
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 change
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 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 oug
El día 23 de diciembre de 2010 13:35, Arjen Markus
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 one
> picks this up,
El día 23 de diciembre de 2010 13:41, Arjen Markus
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
>
> On 2010-12-2
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:35, Arjen Markus
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 one
> picks this up,
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 w
El día 23 de diciembre de 2010 09:55, José Luis García Pallero
escribió:
>> On 2010-12-22 22:05-0700 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
>>> al
> On 2010-12-22 22:05-0700 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
>>
Hi,
On 2010-12-23 06:05, 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 small
On 2010-12-22 22:05-0700 Maurice LeBrun wrote:
> 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 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 Pall
On 2010-12-22 23:15- Andrew Ross wrote:
> 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
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
43 matches
Mail list logo