[Plplot-devel] Helping you to collect evidence to support a fill-rule bug report for wxWidgets on Windows

[Alan W. I. <ir...@be...>]

On 2017-10-01 09:49+0100 Phil Rosenberg wrote:

>>> Note that I have tested this up to the point of checking in the
>>> debugger that the correct fill rule is recognised by the viewer and
>>> the correct parameter is passed in to the wxWidgets fill function.
>>> This definitely works correctly both with and without -eofill
>>> specified for example 27. However I didn't spot a difference in the
>>> output. Maybe you can check it if you know how it should look
>>
>>
>> Hi Phil:
>>
>> I suspect you didn't go far enough into the pages of the example to
>> encounter the fill results for the more complex figures. If you do
>> that, e.g., page 19 of the example (see
>> <http://www.plplot.org/examples-data/demo27/x27.19.png> which was
>> generated with -dev pngcairo and the -eofill option), the result
>> should have many holes in the fill region relative to the same page
>> generated without the -eofill option.  If you don't see that
>> difference on Windows, I feel that is likely due to a wxWidgets
>> library bug on Windows since that difference does show up in the Linux
>> case.
>>
>> Anyhow, thanks very much for this fix, and I have changed the status
>> of https://sourceforge.net/p/plplot/bugs/174/ to closed-fixed.
>
> I get output just like that image without the -eofill parameter. I
> suspect that as you said this is a bug in wxWidgets on Windows. I'm
> not exactly sure how the differences are supposed to manifest. If you
> could send me a relatively simple polygon that should give different
> output depending upon which rule is used and a description of what
> should be different then I will generate a test case and submit a bug
> report.

I think the best test case is a considerably simplified version of C
standard example 27 with the lowest-order figure that shows the
difference.  I therefore as requested have attached source code for
such a test case, and associated screenshots for -dev wxwidgets in the
two fill-rule cases (snapshot1.png for the default case without
-eofill and snapshot2.png for the case with -eofill).  If you compare
those screenshots with the figure in
<https://en.wikipedia.org/wiki/Nonzero-rule> you will see (as
expected) that snapshot1.png follows the non-zero fill rule and
snapshot2.png follows the even-odd fill rule.  These results were
produced on a Linux platform, but from what you say on a Windows
platform you would always get for this simplified test case the
equivalent of the -eofill result.  So once you confirm that, it would
be pretty good evidence of a wxWidgets library bug in the Windows
case.

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
__________________________