| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
| |
Record the nesting level when finding the edge winding contribution
so that inner edges can be reversed as needed.
R=fmalita@chromium.org
BUG=skia:3838
Review URL: https://codereview.chromium.org/1140383002
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
added, and reverse windings if the contours are nested in other contours.
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.org
TBR=reed@google.com
BUG=skia:3838
Review URL: https://codereview.chromium.org/1129193006
|
|
|
angle sort order to initialize the winding. This never worked correctly with cubics and was flaky with paths consisting mostly of vertical edges.
This replacement shoots axis-aligned rays through all intersecting edges to find the outermost one either horizontally or vertically. The resulting code is smaller and twice as fast.
To support this, most of the horizontal / vertical intersection code was rewritten and standardized, and old code supporting the top-directed winding was deleted.
Contours were pointed to by an SkTDArray. Instead, put them in a linked list, and designate the list head with its own class to ensure that methods that take lists of contours start at the top. This change removed a large percentage of memory allocations used by path ops.
TBR=reed@google.com
BUG=skia:3588
Review URL: https://codereview.chromium.org/1111333002
|
caryclark