[cairo-bugs] [Bug 34994] New: cairo bitmapped (png) results do not fill self-intersecting boundaries correctly

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=34994

           Summary: cairo bitmapped (png) results do not fill
                    self-intersecting boundaries correctly
           Product: cairo
           Version: 1.8.10
          Platform: x86-64 (AMD64)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: png functions
        AssignedTo: cworth at cworth.org
        ReportedBy: irwin at beluga.phys.uvic.ca
         QAContact: cairo-bugs at cairographics.org


The PLplot development team have just implemented a demanding 2D fill rendering
test where we modify our standard example 27 (see
http://plplot.sourceforge.net/examples.php?demo=27) to change from drawing the
boundary line of "spirographic" (e.g., hypotrochoid and epitrochoid) curves to
filling those curves.  In general, on Linux (specifically Debian Squeeze) the X
results for these self-intersecting boundaries are not filled correctly (either
for the even-odd or non-zero winding number fill rules), and I have made the
appropriate bug report at https://bugs.freedesktop.org/show_bug.cgi?id=34877
concerning those X fill issues.

Along with the pure X "xwin" device driver, PLplot also has a device driver
based on the pango/cairo library stack that provides the following devices on
Linux: "xcairo" (X backend), "svgcairo" (SVG backend), "pscairo" (PostScript
backend), "pdfcairo" (PDF backend), and "pngcairo" (bitmapped surface for
cairo).  All these cairo devices show exactly the same two classes of fill
errors for the two different filling rules as the "xwin" device.  Most of these
can be dismissed as exactly the same X error as reported above since xcairo
obviously uses X, and svgcairo, pscairo, and pdfcairo produce files that are
viewed using a viewer that presumably ultimately renders the fills using X. 
But I am not sure whether the same argument can be made for pngcairo since that
is a bitmapped result.  In that case cairo (or possibly some independent
library such as X) must render the fills (incorrectly for both the odd-even and
non-zero filling rules) before the resulting png file is viewed.

If you want to verify this bitmapped fill error for yourself, follow the PLplot
svn trunk CMake-based build instructions given in the above bug report (which
should only take a few minutes), but instead of building the xwin device, you
build all the cairo devices with

make cairo

and the 27th example with

make x27c

Afterwards you run that example as follows from the build tree:

# even-odd filling rule:
examples/c/x27c -dev pngcairo -o testeo.pngcairo -fam -eofill

# non-zero filling rule:
examples/c/x27c -dev pngcairo -o test.pngcairo -fam

(The purpose of the -fam option is to separate the various pages of the example
into separate files and the purpose of the -eofill option is to specify the
even-odd filling rule as opposed to the non-zero winding number fill rule that
is used if that option is not specified.)  Then view the results using, e.g.,

display testeo.pngcairo.14

(to display the 14th page [which shows major filling errors] of the example
that uses the even-odd fill rule).

If it turns out that even the bitmapped pngcairo results have fills done with
X, then this bug should be closed so that everybody with an interest in
correcting these fill problems for self-intersecting boundaries can concentrate
on the above X bug report.  On the other hand, my understanding is that the
cairo developers have lots of rendering expertise so regardless of that issue I
hope they help to figure out not only the current pngcairo fill problem
discussed here, but also the general X fill problems.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.