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 <https://en.wikipedia.org/wiki/Nonzero-rule>.
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 <device>
and
examples/c/x27c -dev <device> -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.
<aside> 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 <http://docs.wxwidgets.org/3.0/classwx_d_c.html> 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. </aside>
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
