In some cases, two edges can be collinear when tested on one side
(e.g., left top vs right edge), but non-collinear when tested on the
other (e.g., right top vs left edge). We were actually merging based
on one criterion, but assserting based on the other.
The safest fix is to merge if either condition is true, and then
assert that both conditions are false.
Bug: 866319
Change-Id: Ia1be330caf62f6d7961746752f73993ca098d0a3
Reviewed-on: https://skia-review.googlesource.com/143501
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
When three collinear edges occur during the sanitize_contours() pass,
their vertices may not yet have been discovered to be coincident. So
we must do the vertex comparison by point, rather than by pointer.
Bug: 860655
Change-Id: I89dc7526905bb5473206661348fee431371731a0
Reviewed-on: https://skia-review.googlesource.com/141523
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Some "missing" intersections (see
https://skia.googlesource.com/skia/+/89042d5f13a56d6b663657aa58f17593123a344e)
cause the active edge list to go out of order. In that case, we need
to rewind the active list, just as we do before edge splitting for
regular intersections.
BUG=860453
Change-Id: I1f7b32157a73b427a4fd94c14c1eb440f26c0743
Reviewed-on: https://skia-review.googlesource.com/141038
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Removes circular dependencies from coming change.
Some IWYU fallout from removing #includes from GrPathRenderer.h and
GrDrawingManager.h
Bug: skia:
Change-Id: Ice377538e6d64b6a74a59e6140e1de9a58ab99bf
Reviewed-on: https://skia-review.googlesource.com/140181
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Brian Salomon <bsalomon@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
In some cases, splitting may produce three consecutive edges which
are collinear. The first one was being merged out, causing the third
one to be missed.
The fix is to switch the arguments to merge_edges_*, ensuring that the
second parameter (the destination edge) is never merged out.
Bug: 851409
Change-Id: I65be2e8222846c99f7bc8d17ea61ddead617cc31
Reviewed-on: https://skia-review.googlesource.com/138700
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
This reverts commit 26bb0e66f2.
Reason for revert: segfaulty
Here's a log with a stacktrace:
https://chromium-swarm.appspot.com/task?id=3e658f7aa40dbb10&refresh=10
Original change's description:
> GrTessellator: handle three consecutive collinear edges.
>
> In some cases, splitting may produce three consecutive edges which
> are collinear. The first one was being merged out, causing the third
> one to be missed.
>
> The fix is to switch the arguments to merge_edges_*, ensuring that the
> second parameter (the destination edge) is never merged out.
>
> Bug: 851409.
> Change-Id: I70fbbc506e97a26b259c1443b6d1787adec0f9b0
> Reviewed-on: https://skia-review.googlesource.com/138561
> Reviewed-by: Robert Phillips <robertphillips@google.com>
> Commit-Queue: Stephen White <senorblanco@chromium.org>
TBR=robertphillips@google.com,senorblanco@chromium.org
Change-Id: I6ecfb4c487d6f96e9fae7b8b40d74162354ed57c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 851409.
Reviewed-on: https://skia-review.googlesource.com/138640
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
In some cases, splitting may produce three consecutive edges which
are collinear. The first one was being merged out, causing the third
one to be missed.
The fix is to switch the arguments to merge_edges_*, ensuring that the
second parameter (the destination edge) is never merged out.
Bug: 851409.
Change-Id: I70fbbc506e97a26b259c1443b6d1787adec0f9b0
Reviewed-on: https://skia-review.googlesource.com/138561
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
If the last vertex in a contour is collinear with its neighbours,
remove it (this edge case was missing). Otherwise, the simplify step
may try to split it indefinitely.
Bug: 851409
Change-Id: I7efa4e616cdc1508a73c7a9f3de9d3f571569af8
Reviewed-on: https://skia-review.googlesource.com/138106
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Sometimes the intersector will return an intersection which is on the
same primary sort criterion (eg., Y coordinate), but out-of-range on the
secondary. We shouldn't do splits in this case. The only case we really
care about is if it's less than one epsilon and greater than zero,
and thus numerically unsplittable.
Bug: 851914
Change-Id: Ia772763b6a66a14ca159cf409a832835244e83bc
Reviewed-on: https://skia-review.googlesource.com/136803
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Sometimes the intersection check will miss an intersection (because
floating point). This can leave the active edge list in an invalid
state, where an edge pair is incorrectly ordered. The fix is to test
for edge crossings after testing for intersections, and split the
edges manually. This extra check may result in a performance hit, so
we'll have to watch the perf bots carefully.
Bug: 843135
Change-Id: If50320413026be503cdb2d33e6c97f620e4d51a9
Reviewed-on: https://skia-review.googlesource.com/133400
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
It's actually possible for an intersection to be out-of-range on both
the intersected edges (e.g., below both bottom points), because
floating point. So we need to clamp against both edges.
Bug: 846014
Change-Id: I9fe25a1fcd3b5242af7b1ee36b17f1e968aeb836
Reviewed-on: https://skia-review.googlesource.com/132323
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Most of this is (obviously) not necessary to do, but once
I started, I figured I'd just get it all. Tools (nanobench,
DM, skiaserve), all GMs, benches, and unit tests, plus support
code (command line parsing and config stuff).
This is almost entirely mechanical.
Bug: skia:
Change-Id: I209500f8df8c5bd43f8298ff26440d1c4d7425fb
Reviewed-on: https://skia-review.googlesource.com/131153
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
When support for out-of-range intersections was added in
3b5a3fa8b1, it was intended to support
splitting edges that are almost flat, where merging with the top or
bottom vertex would cause visual artifacts. However, it triggers too
often for other, non-nearly-flat cases, causing simplify() to loop
infinitely.
The fix is to support out-of-range intersections only if they differ by
1/2 machine epsilon. This also generalizes the
out_of_range_and_collinear() check, so it was removed.
Bug: 838978
Change-Id: I238f2b90e4b7ad647ecf072427ee38726e549581
Reviewed-on: https://skia-review.googlesource.com/130458
Reviewed-by: Stephen White <senorblanco@chromium.org>
This reverts commit bfb2a05af1.
Reason for revert: Seems to cause failures in chromeos and chromecast test bots. eg:
https://chromium-swarm.appspot.com/task?id=3dc5be8269e3b410&refresh=10https://chromium-swarm.appspot.com/task?id=3dc5d62dfdc99010&refresh=10
Original change's description:
> GrTessellator: fix for ping-pong split fuzzer hang.
>
> Change 3b5a3fa8b1 introduced support for
> splitting on out-of-range intersections. However, this is only necessary
> for correctness when the edge is nearly-flat (the top and bottom
> points only differ by 1/2 machine epsilon in the primary sort criterion).
> In other cases, it can cause repeated splitting and re-merging of edges,
> as the intersection code (being approximate and not exact) may produce a
> ping-pong set of intersections.
>
> The fix is to support out-of-range intersections only if they differ by
> 1/2 machine epsilon. This also generalizes the
> out_of_range_and_collinear() check, so it was removed.
>
> Bug: 838978
> Change-Id: I134f7eff3f15707e0d68de11c55f7fadce4ff8e7
> Reviewed-on: https://skia-review.googlesource.com/130448
> Reviewed-by: Robert Phillips <robertphillips@google.com>
> Commit-Queue: Stephen White <senorblanco@chromium.org>
TBR=robertphillips@google.com,senorblanco@chromium.org
Change-Id: I3fa62423d3875665397adcecb94b467b9b6611cc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 838978
Reviewed-on: https://skia-review.googlesource.com/130522
Reviewed-by: Ravi Mistry <rmistry@google.com>
Commit-Queue: Ravi Mistry <rmistry@google.com>
Change 3b5a3fa8b1 introduced support for
splitting on out-of-range intersections. However, this is only necessary
for correctness when the edge is nearly-flat (the top and bottom
points only differ by 1/2 machine epsilon in the primary sort criterion).
In other cases, it can cause repeated splitting and re-merging of edges,
as the intersection code (being approximate and not exact) may produce a
ping-pong set of intersections.
The fix is to support out-of-range intersections only if they differ by
1/2 machine epsilon. This also generalizes the
out_of_range_and_collinear() check, so it was removed.
Bug: 838978
Change-Id: I134f7eff3f15707e0d68de11c55f7fadce4ff8e7
Reviewed-on: https://skia-review.googlesource.com/130448
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
When merging coincident vertices, sometimes merging an edge will cause
the next edge in the list to die. But since merge_vertices() retrieves
the next edge before merging the current one, we then try to merge its
lifeless corpse, bringing it back as a zombie. The fix is to leave
dead edges, dead.
This was revealed by ec79c39a77, but was
likely a real bug that was being mishandled before that.
Bug: 844873
Bug: skia:7982
Change-Id: I752c45f7551df4278fa4cb4587e7ead48cd16a21
Reviewed-on: https://skia-review.googlesource.com/129524
Commit-Queue: Stephen White <senorblanco@chromium.org>
Reviewed-by: Robert Phillips <robertphillips@google.com>
While splitting one edge, merge_collinear_edges() may in rare cases
merge the other edge of the intersection out of existence.
split_edge() then brings these dead edges partially back to life,
leaving the mesh in an inconsistent state.
The fix is to null out the top and bottom pointers of dead edges to
mark them as dead, and only split living edges.
Bug: skia:7911
Change-Id: I1c0b59581acfcd0b8191f2d129b33f7d0d1a2516
Reviewed-on: https://skia-review.googlesource.com/129181
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
This reverts commit 2097fd03ff.
Reason for revert: This is breaking a lot of Windows bots (esp. on the shadermaskfilter_localmatrix)
Original change's description:
> Fix handling of MaskFilter matrices
>
> 1) extend GrFPArgs to track pre/post local matrices, add helpers for
> creating pre/post wrapper args
>
> 2) add a SkShaderBase helper (totalLocalMatrix) to centralize the LM
> sandwich logic.
>
> 3) update call sites to use the above
>
> 4) rename SkMatrixFilter::makeWithLocalMatrix -> makeWithMatrix, to
> disambiguate vs. SkShader::makeWithLocalMatrix.
>
> BUG=skia:7744
>
> Change-Id: Ib2b7b007e6924979b00649dde7c94ef4b34771f1
> Reviewed-on: https://skia-review.googlesource.com/119330
> Commit-Queue: Florin Malita <fmalita@chromium.org>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
TBR=bsalomon@google.com,robertphillips@google.com,fmalita@chromium.org,reed@google.com
Change-Id: I918dbb95bf00b3122e6699b84566ec82dbb5fc5c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:7744
Reviewed-on: https://skia-review.googlesource.com/120340
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
1) extend GrFPArgs to track pre/post local matrices, add helpers for
creating pre/post wrapper args
2) add a SkShaderBase helper (totalLocalMatrix) to centralize the LM
sandwich logic.
3) update call sites to use the above
4) rename SkMatrixFilter::makeWithLocalMatrix -> makeWithMatrix, to
disambiguate vs. SkShader::makeWithLocalMatrix.
BUG=skia:7744
Change-Id: Ib2b7b007e6924979b00649dde7c94ef4b34771f1
Reviewed-on: https://skia-review.googlesource.com/119330
Commit-Queue: Florin Malita <fmalita@chromium.org>
Reviewed-by: Brian Salomon <bsalomon@google.com>
stroke -> Inf -> NaN -> assert.
BUG=skia:7775
Change-Id: I086883bce90d1d473cff87f67e954718ea3181f6
Reviewed-on: https://skia-review.googlesource.com/118145
Commit-Queue: Stephen White <senorblanco@chromium.org>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This is a reland of 050c86768a
Original change's description:
> GrTessellator: hang fix.
>
> Some edges are not coincident with their own endpoints (because floating
> point). If this happens for an edge which is a right-enclosing-edge
> during the Bentley-Ottman simplify() pass, we end up an infinite loop
> attempting to split the edge, since the edge is never to the right of its
> endpoint.
>
> The easiest fix is to simply remove the right-enclosing-edge splitting
> code. This code was originally added before we had proper
> active-edge-list rewinding, and should no longer be necessary.
>
> BUG=802896
>
> Change-Id: Id9f2942b73f01152af8c0088e8c6b1389891d827
> Reviewed-on: https://skia-review.googlesource.com/116920
> Reviewed-by: Robert Phillips <robertphillips@google.com>
> Commit-Queue: Stephen White <senorblanco@chromium.org>
Bug: 802896
Change-Id: I3e48346a8a358ae7d481299a586003e817a519ca
Reviewed-on: https://skia-review.googlesource.com/117121
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This reverts commit 050c86768a.
Reason for revert: layout test diff in Chrome roll?
Original change's description:
> GrTessellator: hang fix.
>
> Some edges are not coincident with their own endpoints (because floating
> point). If this happens for an edge which is a right-enclosing-edge
> during the Bentley-Ottman simplify() pass, we end up an infinite loop
> attempting to split the edge, since the edge is never to the right of its
> endpoint.
>
> The easiest fix is to simply remove the right-enclosing-edge splitting
> code. This code was originally added before we had proper
> active-edge-list rewinding, and should no longer be necessary.
>
> BUG=802896
>
> Change-Id: Id9f2942b73f01152af8c0088e8c6b1389891d827
> Reviewed-on: https://skia-review.googlesource.com/116920
> Reviewed-by: Robert Phillips <robertphillips@google.com>
> Commit-Queue: Stephen White <senorblanco@chromium.org>
TBR=robertphillips@google.com,senorblanco@chromium.org
Change-Id: Icb928db6c052a21c6d327da9492cb991f769186f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 802896
Reviewed-on: https://skia-review.googlesource.com/117120
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Some edges are not coincident with their own endpoints (because floating
point). If this happens for an edge which is a right-enclosing-edge
during the Bentley-Ottman simplify() pass, we end up an infinite loop
attempting to split the edge, since the edge is never to the right of its
endpoint.
The easiest fix is to simply remove the right-enclosing-edge splitting
code. This code was originally added before we had proper
active-edge-list rewinding, and should no longer be necessary.
BUG=802896
Change-Id: Id9f2942b73f01152af8c0088e8c6b1389891d827
Reviewed-on: https://skia-review.googlesource.com/116920
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
A mechanical bulk move just to get these out of the public API.
TBR=bsalomon@google.com
Change-Id: I813efbd54a09dd448275697c0e50947753a5cfd3
Reviewed-on: https://skia-review.googlesource.com/112262
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Bug: skia:
Change-Id: Id9df92b76c9f948f41f4108bcecdb2687233f841
Reviewed-on: https://skia-review.googlesource.com/110761
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
This reverts commit 3a2cc2c2ec.
Fix code with samplecnt=0 that slipped in between trybots/CQ and landing of previous version
Change-Id: Iab19f2e8d1e9901601c8c76244d7a88c5d707fab
Reviewed-on: https://skia-review.googlesource.com/103181
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This reverts commit 5bb82cbecd.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> Revert "Revert "Revert "Revert "Redefine the meaning of sample counts in GPU backend.""""
>
> This reverts commit 18c52a7b52.
>
> Also relands "More sample count cleanup:" and "Add new GrContext queries for imagability, surfacability, and max sample count of color types"
>
>
> Bug: skia:
> Change-Id: I4028105a3a1f16ce3944e134619eb6245af6b947
> Reviewed-on: https://skia-review.googlesource.com/102940
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
TBR=egdaniel@google.com,bsalomon@google.com
Change-Id: Idee23be2f1719f0bdc9305043e95a2d589bee8d1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/103220
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This reverts commit 18c52a7b52.
Also relands "More sample count cleanup:" and "Add new GrContext queries for imagability, surfacability, and max sample count of color types"
Bug: skia:
Change-Id: I4028105a3a1f16ce3944e134619eb6245af6b947
Reviewed-on: https://skia-review.googlesource.com/102940
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This reverts commit d0d7270fcc.
Revert "More sample count cleanup:"
This reverts commit d653cac70e.
Revert "Add new GrContext queries for imagability, surfacability, and max sample count of color types"
This reverts commit 85ae7159c9.
Need to understand NVPR perf changes before relanding
Change-Id: I0db075fb42438ef2a1f9885df184dce52892ac4b
Reviewed-on: https://skia-review.googlesource.com/102780
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Fixes gpu config default samples to be 1 and updates config parsing test accordingly.
This reverts commit c1ce2f7966.
Bug: skia:
Change-Id: I456973b1f52ced85a2011ea10fc49449bfc5846f
Reviewed-on: https://skia-review.googlesource.com/102147
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This reverts commit 48825b11ad.
Reason for revert: nanobench
Original change's description:
> Redefine the meaning of sample counts in GPU backend.
>
> Old: 0 -> nonMSAA
> 1+ -> MSAA
>
> New:
> 0 -> error/unsupported
> 1 -> nonMSAA
> 2+ -> MSAA
>
> We still allow 0 to mean nonMSAA in three sets of public APIs for backwards compatibility:
>
> 1) SkSurface factories
> 2) GrBackendRenderTarget constructors
> 3) GrCaps::getSampleCnt()'s requestedCount parameter
>
> However, we immediately clamp to 1 and treat 0 as invalid/non-renderable internally.
>
> This also changes the behavior when using a large sample count. We now fail in that case rather than using the largest sample available sample count. GrCaps::getSampleCount() will return 0 in this case.
>
>
> Bug: skia:
> Change-Id: Ida22c6b22c1365e563c9046b611e88bf5eb3ff33
> Reviewed-on: https://skia-review.googlesource.com/101560
> Reviewed-by: Greg Daniel <egdaniel@google.com>
> Commit-Queue: Brian Salomon <bsalomon@google.com>
TBR=egdaniel@google.com,bsalomon@google.com
Change-Id: Ic257619a8a5ee9ac15419ecf10259e42daed7f82
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/102662
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Old: 0 -> nonMSAA
1+ -> MSAA
New:
0 -> error/unsupported
1 -> nonMSAA
2+ -> MSAA
We still allow 0 to mean nonMSAA in three sets of public APIs for backwards compatibility:
1) SkSurface factories
2) GrBackendRenderTarget constructors
3) GrCaps::getSampleCnt()'s requestedCount parameter
However, we immediately clamp to 1 and treat 0 as invalid/non-renderable internally.
This also changes the behavior when using a large sample count. We now fail in that case rather than using the largest sample available sample count. GrCaps::getSampleCount() will return 0 in this case.
Bug: skia:
Change-Id: Ida22c6b22c1365e563c9046b611e88bf5eb3ff33
Reviewed-on: https://skia-review.googlesource.com/101560
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This prepares us to share this with other effects (most notably maskfilters)
Bug: skia:
Change-Id: I12530fdf10c4e5f2a9ab6d394bf9e87c54ea60c4
Reviewed-on: https://skia-review.googlesource.com/97062
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Some pathological cases don't converge to a reasonable number of points
when using uniform linearization of quadratic points. Cap them to the
maximum which GrPathUtils supports.
Add reduced test case from crbug-762369.
BUG=762369
Change-Id: Icc744018e5c01a0e0fe2ec00613bdb25e49614e9
Reviewed-on: https://skia-review.googlesource.com/92721
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
With some large values, intersection for bevelling will fail.
These should just skip the point, not assert.
BUG=798912
Change-Id: Ie5c8cc3c9387055e1e31480321a231f0e6ff153b
Reviewed-on: https://skia-review.googlesource.com/91141
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
If input points are near-infinite, they may become inf or NaN when
stroked. Before converting the results of intersection from double
to float, clamp them to the [-FLT_MAX/FLT_MAX] range.
BUG=798679
Change-Id: I7d61130dd26147a9b7cfd38aa96567e3867b5c3e
Reviewed-on: https://skia-review.googlesource.com/90983
Commit-Queue: Stephen White <senorblanco@chromium.org>
Reviewed-by: Brian Osman <brianosman@google.com>
This CL implements two major changes to the AA tessellating path
renderer:
1) Fix inverted edges after stroke and simplify. Instead of detecting
and fixing edges which invert on stroking during the stroking pass, we
run the full simplify pass on both inner and outer contours, then
create edge collapse events for the overlap regions. We then process
the edge events in a priority queue and process them in order of decreasing
alpha (this is the "edge event" part of the straight skeleton
algorithm). By doing it after simplification, we ensure that
there's a full-alpha intersection vertex to join the collapse edge
to (which may have <1 alpha), so no spurious gradients appear in
the rendered path.
2) "Pointy" vertices (defined as those which meet at an acute angle less
than 14 degrees) are now properly bevelled off during stroking.
This removes antialiasing artifacts which extend beyond the path
boundary.
Some ancillary changes:
The extracted boundaries which are input to stroking have their line
equations pre-normalized, and multiplied by winding. This simplifies
a lot of code which was performing this computation on the fly.
The workaround for the "intruding vertex" problem was removed, since the
straight skeleton now moves the intruding vertex before it can cause
problems.
Bug: 756823
Change-Id: I271ed32be6847da55273b387e8c04bbf9b512b70
Reviewed-on: https://skia-review.googlesource.com/87341
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Also fixes some bugs involved with creating mipped SkSurfaces.
Bug: skia:
Change-Id: I6e0109000eadd2bdee4a907d3ee2231104528165
Reviewed-on: https://skia-review.googlesource.com/65063
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Also to SkColorTo(Premul|Unpremul)GrColor4f.
This can avoid cache lookups to find GrColorSpaceXforms as the xform pointer is stored in GrColorSpaceInfo after the first lookup.
Also uses GrColorSpaceInfo to construct GrTextUtils::Paint.
Bug: skia:
Change-Id: Idf19d512a60d2269e6921c7fb54d93aee499a70d
Reviewed-on: https://skia-review.googlesource.com/63660
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Gives the convex and tessellating renderers first claim on larger
paths, and the distance field renderer first claim on complex,
non-volatile paths. This also requires plumbing the clip bounds
through GrPathRenderer::CanDrawPathArgs.
Bug: skia:
Change-Id: I16e1d35ad5ee63251e33f113b1579cbba60456da
Reviewed-on: https://skia-review.googlesource.com/42224
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
This is then used when need to update GPU only buffers with data of size
greater than 65536. We create a temporary transfer buffer and then copy
that buffer into our GPU buffer.
Bug: skia:
Change-Id: I4bb9cb660f2ac1ccbbd1b508bb4ca6876342136f
Reviewed-on: https://skia-review.googlesource.com/38725
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
NaNs can't be correctly sorted.
Don't run the unit test on VK backend, since it requires large (>64K bytes) vertex buffer uploads.
Bug: 757650
Change-Id: I667693f135a090a5d9076bb7a2ec6879fc06d645
Reviewed-on: https://skia-review.googlesource.com/37484
Commit-Queue: Stephen White <senorblanco@chromium.org>
Reviewed-by: Greg Daniel <egdaniel@google.com>
NaNs can't be correctly sorted.
Bug: 757650
Change-Id: Id1ca2fe1d1de7884da2a64ceef9491b1da7e8e77
Reviewed-on: https://skia-review.googlesource.com/37220
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Change 3b5a3fa8b1 introduced support
for out-of-range intersections, which is necessary when the top and
bottom vertices of an edge differ by only one ULP in the primary sort
order and can't be split in-order.
However, some out-of-range intersections produce edges which cancel
each other out on splitting, in particular when the intersection is
collinear with the newly-computed edge. This undoes the effect of the
split. The tessellator then rewinds, re-detects the intersection, resplits,
an infinite loop.
The fix is to check for out-of-range intersections which are also
collinear, and ignore them. This is ok, because these are not
the cases we care about it change 3b5a3f above, which are
never collinear.
Bug: 753867
Change-Id: I590231e0e6f19c98f1ccf46cb7acc8a63ba35a9d
Reviewed-on: https://skia-review.googlesource.com/34925
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Change-Id: I985e54a071338e99292a5aa2f42c92bc115b4008
Reviewed-on: https://skia-review.googlesource.com/32760
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The only substantive changes are the removal of GrProxy instantiation in:
SkGpuBlurUtils::GaussianBlur
GrSimpleTextureEffect::Make*
Change-Id: I10970609693bd6ff5b3a3c21b41d82642bb277bc
Reviewed-on: https://skia-review.googlesource.com/19965
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
If a point in the path rounds to +inf/-inf, the intersection code can
produce NaN, which is unsortable. Fix: ignore non-finite intersections.
Quadratic interpolation can sometimes produce NaN, which will never
satisfy the flatness criterion. Abort if any of the interpolated points
are non-finite.
Bug:732023
Change-Id: If5881796e589c75b8f74459f42d00918619713a2
Reviewed-on: https://skia-review.googlesource.com/19467
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Change-Id: Iaded9025a1518d8c69dbe366deb1035e0bd4295b
Reviewed-on: https://skia-review.googlesource.com/19289
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
