crbug.com/526025 includes a minimized SVG test case.
Translating that test case into native code (fuzzTNG)
did not reproduce the bug. That test case should
have not been included with skia issue 1323813003,
and is deleted here.
Running the minimal test case in a modified version
of chrome isolated the bug. The modified version
generated the test fuzz763_3 with the edit
#define DEBUGGING_PATHOPS_FROM_HOST 1
in src/pathops/SkPathopsOp.cpp line 188.
Rename fuzz763_3 to issue_526025 to associate the test
with the bug. Note that the bug contains the body of the
CL in comment $5.
R=reed@google.com
Review URL: https://codereview.chromium.org/1315503005
The list of intersection points on a curve segment may have
entries that can be safely removed when nearby points have
nearly the same t value and point value. When a path includes
very large curves as well as small ones, as is the case with
this fuzzer, additional points may lie between the similar
points that do not meet the nearby criteria.
After merging the nearby point with its doppelganger,
SkOpSegment::moveNearby() unnecessarily set the doppelganger's
next pointer to the one following the nearby point. While
this usually has no effect, since the merge already updated
the linked list, the explicit call removes the additional
outlier points from the segment.
TBR=reed@google.com
BUG=526025
Review URL: https://codereview.chromium.org/1323813003
A path can be non-empty but become empty when it is simplified.
For instance, a path with the same rectangle, twice, with opposite
windings.
No contours are created for empty paths, so don't try to
fix their winding direction.
Additionally, check for a NULL coincidence since the
OpBuilder assumes that no concidence edges can be present
after the paths are simplified. This code should not get
called, but it's worth the future-proofing to check.
R=fmalita@chromium.org
BUG=502792
Review URL: https://codereview.chromium.org/1218863005
Cheap (one contour) paths can be evaluated and reversed as needed with a minimum of checking, but multi-contour paths invoke the regular path ops machinery to determine who is contained by whom.
More tests need to be added to verify that all corner cases are considered, but this fixes the cases in the bug thus far.
R=fmalita@chromium.orgTBR=reed@google.com
BUG=skia:3838
Review URL: https://codereview.chromium.org/1129193006
The rewrite of path ops caused the inner contour direction to be reversed.
This exposed an existing bug in path ops builder, namely that the implicit
winding of the internal sum path could hide inner contours if they ended
up in the wrong direction.
Setting the sum path's fill type to even-odd ensures that the inner
contours aren't discarded.
R=fmalita@chromium.org
BUG=skia:3838
Review URL: https://codereview.chromium.org/1126193004
Replace the implicit curve intersection with a geometric curve intersection. The implicit intersection proved mathematically unstable and took a long time to zero in on an answer.
Use pointers instead of indices to refer to parts of curves. Indices required awkward renumbering.
Unify t and point values so that small intervals can be eliminated in one pass.
Break cubics up front to eliminate loops and cusps.
Make the Simplify and Op code more regular and eliminate arbitrary differences.
Add a builder that takes an array of paths and operators.
Delete unused code.
BUG=skia:3588
R=reed@google.com
Review URL: https://codereview.chromium.org/1037573004
There's no gyp references to these new files,
so this should only have the effect of reducing
the size of the commit that turns this code on.
TBR=
Review URL: https://codereview.chromium.org/853223002
