Re: [Plplot-devel] I am having trouble figuring out why the -eofill command-line optionis being ignored for -dev wxwidgets

[Alan W. Irwin]

On 2017-09-30 02:27+0100 p.d.rosenb...@gmail.com wrote:


I suspect this will be a bug in the render buffer, where the fill

method is not correctly stored in or read from the buffer. You can
check this by doing a plreplot with and device and seeing if the
correct behaviour is maintained.

To Phil and Jim:

@Jim:

I am specifically also addressing you in this discussion because of
your knowledge of the plbuf code so I hope you will be able to reply
to the final question below.

@Phil:

Thanks for your explanation of why rendering operations would be
no-ops when using gdb on an example such as

examples/c/x27c

for the -dev wxwidgets case.

Also, I have some contradictory evidence regarding what you suspect
above.  For example when I search src/plbuf.c for "eofill" there is
nothing.  Also, when I search that code for anything to do with fills,
the fill state appears to only include information concerning discrete
fills (with line patterns as in example 15) rather than information
like pls->dev_eofill that is needed for solid fills.  So I suspect
adding that information to the fill state might solve this issue.

However, without attempting to make such a change (yet) if I run

examples/c/x27c -dev qtwidget -eofill

or

examples/c/x27c -dev xwin -eofill

I get the correct behaviour (an odd-even rule fill) regardless of
whether I resize the GUI or call plreplot after each call to
spiro in examples/c/x27c.c.  Aren't both of those actions supposed
to use the plbuf code to replot the buffer?  And from the above
search of the src/plbuf.c code how is it possible that 
pls->dev_eofill is used properly by this code when no

reference to that exists within that code.

@Phil and Jim:

I obviously must be missing something about the plbuf code, but what?

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] [Bug] Plmap omits lines at the left hand side ofthe map

[Alan W. Irwin]

On 2017-09-30 02:39+0100 p.d.rosenb...@gmail.com wrote:




Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 29 September 2017 20:31
To: Phil Rosenberg
Cc: Mark de Wever; plplot-dev



For those who may now how plfill works a bit better than me, something
that is supported by shapefiles, but currently not by plmap, is holes.
A polygon in a shapefile consists of multiple parts and clockwise
parts are filled whereas anticlockwise parts are holes. Is this
something we can do relatively easily with plfill or is it not really
doable?


I don't think that such a major change to plfill would be a good idea.
For example, calls to plsurf3d (example 8) and plshades (example 16)
end up at the lowest level as many different calls to plfill where
presumably some end up as anti-clockwise fills and some end up
as clockwise fills in difficult-to-predict ways.

I didn't mean to suggest changing plfill behaviour, just wondered if there was 
some way already to do this.

Therefore, would it be possible for you to honor this shapefile
convention by simply not calling plfill from inside the plmap*
routines whenever they run into an anticlockwise part and by
changing our DocBook documentation of those routines appropriately?




I don't think this works as we have to not render the holes in the

first instance. E.g imagine an island with a lake. We want to fill
just the land, it the lake. This would be a clockwise polygon for the
island and an anticlockwise one for the lake. I think the only way to
do this would be to convert the polygon with its holes to a single
polygon, kind of like a c shape outline but with the ends of the c
touching to make it like an o.

Hi Phil:

It sounds like you are asking if we have the ability to fill a simple
(i.e. non self-intersecting, see
) polygon A
everywhere other than where it intersects with a simple polygon B.

(For your example A would be the polygon describing the island
outline, and B would be the polygon describing the lake outline within
that island.)

If I have described that "not-intersect" case correctly, then the
answer to your question is we do not currently have the ability to
solve that problem.  Which is another example of the truism
that dealing with fill issues always seems to be difficult.

However, that described problem could be solved
with logic rather similar to that needed for solving the general
problem of filling the intersection of two simple polygons.  And we
already do have that capability almost entirely implemented
with the fill_intersection_polygon
routine in src/plfill.c that I implemented back in 2009. That logic
was compiled only if the USE_FILL_INTERSECTION_POLYGON macro is
#defined, and the last commit message that mentioned
USE_FILL_INTERSECTION_POLYGON is as follows:

commit b8be9fcf8de6f5263bdd356a8745ba5878fc3036
Author: Alan W. Irwin 
Date:   Mon Dec 28 17:41:45 2009 +

Fix cases where split 1/split 2 encompasses all/none of the polygon 2
vertices.  This -DUSE_FILL_INTERSECTION_POLYGON=ON change finally gives good
results for the first four pages of example 25, if the clip limits are
shifted around to avoid the case (not implemented yet) where polygon
crossings occur at vertices.

So it appears I have the basic recursive algorithm working correctly, but
there are some details (e.g., polygon crossings at vertices) still to be
implemented.

However, I think that is near the last commit where
I worked on fill_intersection_polygon, because if I recall correctly
if that logic was used for the large number of plfill calls we
generate with our standard examples 8 and 16, I ran into bugs in the
PL_NEAR_* logic.  Therefore, I "temporarily" suspended working on that
logic and never got back to it.

However, two years ago (see your posts with the subject line "Bug in
notcrossed() function of plfill.c" you discovered that our ordinary
fill logic (used when USE_FILL_INTERSECTION_POLYGON is not #defined)
also sometimes fails because of a PL_NEAR_PARALLEL bug.  I have been
putting off solving that bug (although it is certainly on my ToDo list
for this release cycle). However, once that is solved, and the case of
polygon crossings at vertices solved, then it is certainly possible
that fill_intersection_polygon would just work as designed for all our
examples.

Of course, getting this all straightened out is going to take some
substantial time.  So for now, I think you should ignore this shapelib
"hole" convention in the plmap routines while documenting this
limitation as well.  But after the current PL_NEAR_PARALLEL bug is
definitively fixed, you might want to take a look at the
fill_intersection_polygon routine again to see whether you think it is
worth reviving and modifying for the "not-intersect" case that appears
to sometimes be important for shapelib maps.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Ast

[Plplot-devel] I am having trouble figuring out why the -eofill command-line option is being ignored for -dev wxwidgets

[Alan W. Irwin]

Hi Phil:

Just to remind you, all device drivers are supposed to use the
even-odd fill rule if pls->dev_eofill is 1 and the non-zero fill rule
otherwise where the differences between the two fill rules are
nicely illustrated in .
And if you look at the wxPLDevice::FillPolygon code in
drivers/wxwidgets_dev.cpp, all appears to be well, i.e., we
have the following logic:

if ( pls->dev_eofill )
   {
   m_dc->DrawPolygon( pls->dev_npts, points, xoffset, yoffset, 
wxODDEVEN_RULE );
   }
else
   {
   m_dc->DrawPolygon( pls->dev_npts, points, xoffset, yoffset, 
wxWINDING_RULE );
   }

Furthermore, pls->dev_eofill is by default 0, but it can be set to 1
using the -eofill command-line option.  And standard example 27 has lots
of nice pages where plfill is called for complex self-intersecting
paths.

So running that example using, e.g.,

examples/c/x27c -dev 

and

examples/c/x27c -dev  -eofill

illustrates the large differences between the two different fill rules
when the device is one of our interactive devices other than wxwidgets
(e.g., xwin, tk, xwin, xcairo, or qtwidget), but -dev wxwidgets has a
bug where the wxPLViewer app it communicates with only shows the
non-zero fill rule result regardless of whether -eofill is used or
not.

My recent attempt to debug that issue with gdb shows that 
wxPLDevice::FillPolygon does nothing other than to immediately return

because m_dc is NULL.  So although I was able to confirm with gdb that
pls->dev_eofill is set properly by the -eofill command-line option,
the routine never gets to the above m_dc->DrawPolygon calls and some
other wxwidgets-related PLplot logic appears to be responding to
the plfill calls in example 27 using a fixed non-zero fill rule, i.e.,
wxPLViewer rendered fill results use the non-zero fill rule for
that example.

 I am pretty sure from these results that the non-zero fill
rule is likely the default provided by the wxWidgets libraries since
that is the default X, Qt, and pango/cairo library fill rule, and that
(fixed) fill rule is what we are currently getting out of -dev
wxwidgets (and wxPLViewer). Of course, that conclusion is completely
contradicted by  which
states the odd-even fill rule is the default for the wxWidgets
libraries, but I am fairly sure that documentation is just flat-out
wrong in this particular regard. 

So given that background, here are two questions for you which I hope
will be easy for you to answer.

1. Why is m_dc always NULL for repeat calls to plfill effectively
making wxPLDevice::FillPolygon a no-op?

2. What alternative routine in our wxwidgets-related code actually responds to 
calls
to plfill?

Once you give me the answer to 2. I think there is a good chance it
will be a simple matter for me to install pls->dev_eofill testing logic
similar to the above to specify the fill rule we want to be used at
run-time as opposed to the fixed non-zero fill rule that is now being
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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] [Bug] Plmap omits lines at the left hand side of the map

[Alan W. Irwin]

On 2017-09-28 21:31+0100 Phil Rosenberg wrote:


Hi Mark and anyone else who is listening
I have just fixed the map plots. Apologies that this has taken
sooo long. The changes have just been pushed to the development
version and have been checked on my windows machine. Note that you
were correct also about there being an issue with using plmapfill. It
turned out that the type specified in the shapefile was overriding the
render type specified by the user.

While I was there I realised there was a problem with rendering
polygons that wrap round the whole globe such as Antarctica so that
should now be fixed too.



@Mark:

Thanks for spotting these issues that Phil just fixed.

For your information, the git master branch version (what Phil just
pushed) includes an earlier change by me where all the deprecated
plmap cruft was removed.

@Phil:

After fixing up some minor style and trailing space issues (commit
e60fba8 which I just pushed), I tested your changes in the build tree
and for the shared libraries case on Linux using the -DBUILD_TEST=ON
option.  My build of the test_noninteractive target (which build
PLplot libraries, bindings, devices, and examples and which executes
each of our file devices for each of our C examples as well as
comparing -dev psc results for all our supported languages) continues
to work well.  That is, there are no obvious configure, build, or
run-time issue, and no regressions on the remaining (OCaml) PostScript
differences with C example results. I also ran

examples/c/x19c -dev xcairo

, and there are no obvious rendering issues in those results (and
presumably also for all other devices/languages).  I also
built the "validate" target (which tests your DocBook documentation
changes for any validation errors) without issues.

In sum, your current set of changes looks fine to me, and thanks for
this effort!


For those who may now how plfill works a bit better than me, something
that is supported by shapefiles, but currently not by plmap, is holes.
A polygon in a shapefile consists of multiple parts and clockwise
parts are filled whereas anticlockwise parts are holes. Is this
something we can do relatively easily with plfill or is it not really
doable?


I don't think that such a major change to plfill would be a good idea.
For example, calls to plsurf3d (example 8) and plshades (example 16)
end up at the lowest level as many different calls to plfill where
presumably some end up as anti-clockwise fills and some end up
as clockwise fills in difficult-to-predict ways.

Therefore, would it be possible for you to honor this shapefile
convention by simply not calling plfill from inside the plmap*
routines whenever they run into an anticlockwise part and by
changing our DocBook documentation of those routines appropriately?

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] [Bug] Plmap omits lines at the left hand side of the map

[Mark de Wever]

Hi Phil,

On 28.9.17 22:31, Phil Rosenberg wrote:

I have just fixed the map plots. Apologies that this has taken
sooo long. The changes have just been pushed to the development
version and have been checked on my windows machine. Note that you
were correct also about there being an issue with using plmapfill. It
turned out that the type specified in the shapefile was overriding the
render type specified by the user.


Thanks for the fixes.

I just tested with HEAD and the polygon code no longer crashes.

Next I wanted to test with a map with lines and no fill. Unfortunately 
plmapline also draws filled polygons. I did this test with the same 
shapefiles [1] as the original test.


I assume it is caused by the code: src/plmap.c:324
if ( shapetype == SHPT_NULL ) 

{ 

shapetype = fileShapeType; 

} 




The attached patch lets plmapline draw lines instead of filled polygons.

I tested HEAD+patch and the coastal lines no longer disappear, so that 
issue is also fixed.


I will do more testing next week, thanks again for the fixes.


[1] 
http://www.naturalearthdata.com/http//www.naturalearthdata.com/download/50m/cultural/ne_50m_admin_0_countries_lakes.zip


Regards,
Mark de Wever
diff --git a/src/plmap.c b/src/plmap.c
index 58d359a99..694e23fce 100644
--- a/src/plmap.c
+++ b/src/plmap.c
@@ -596,7 +596,7 @@ plmapline( PLMAPFORM_callback mapform, PLCHAR_VECTOR name,
PLINT_VECTOR plotentries, PLINT nplotentries )
 {
 #ifdef HAVE_SHAPELIB
-drawmap( mapform, name, 0.0, 0.0, SHPT_NULL, 0.0, "", minx, maxx,
+drawmap( mapform, name, 0.0, 0.0, SHPT_ARC, 0.0, "", minx, maxx,
 miny, maxy, plotentries, nplotentries );
 #else
 plwarn( "plmapline is a no-op because shapelib is not available." );
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] [Bug] Plmap omits lines at the left hand side of the map

[Phil Rosenberg]

Hi Mark, well spotted. Patch applied. Thanks for the contribution.

On 29 September 2017 at 11:00, Mark de Wever  wrote:
> Hi Phil,
>
> On 28.9.17 22:31, Phil Rosenberg wrote:
>>
>> I have just fixed the map plots. Apologies that this has taken
>> sooo long. The changes have just been pushed to the development
>> version and have been checked on my windows machine. Note that you
>> were correct also about there being an issue with using plmapfill. It
>> turned out that the type specified in the shapefile was overriding the
>> render type specified by the user.
>
>
> Thanks for the fixes.
>
> I just tested with HEAD and the polygon code no longer crashes.
>
> Next I wanted to test with a map with lines and no fill. Unfortunately
> plmapline also draws filled polygons. I did this test with the same
> shapefiles [1] as the original test.
>
> I assume it is caused by the code: src/plmap.c:324
> if ( shapetype == SHPT_NULL )
> {
> shapetype = fileShapeType;
> }
>
>
> The attached patch lets plmapline draw lines instead of filled polygons.
>
> I tested HEAD+patch and the coastal lines no longer disappear, so that issue
> is also fixed.
>
> I will do more testing next week, thanks again for the fixes.
>
>
> [1]
> http://www.naturalearthdata.com/http//www.naturalearthdata.com/download/50m/cultural/ne_50m_admin_0_countries_lakes.zip
>
> Regards,
> Mark de Wever

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel