| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
When there's a single triangle remaining in the monotone,
emit early and skip a convexity check.
BUG=skia:
Change-Id: I591acf4b7f567dbbf7681ba72181e578ca4623ec
Reviewed-on: https://skia-review.googlesource.com/8797
Commit-Queue: Stephen White <senorblanco@chromium.org>
Reviewed-by: Brian Salomon <bsalomon@google.com>
|
|
|
|
|
|
|
|
|
| |
BUG=695696
Change-Id: I1c001316721b3c042cff115c905ff0d2c2698ac0
Reviewed-on: https://skia-review.googlesource.com/9053
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I removed this in https://skia-review.googlesource.com/8028, but that
was actually just masking a problem properly fixed in
https://skia-review.googlesource.com/8364. Now that it is fixed, we
can restore the rounding, which actually improves performance by
5-10% on Canvas Arcs (when run with the tess verb limit disabled).
NOTE: this change will affect many GMs, including strokes_poly,
addarc, parsedpaths, dashcubics, beziers, nested_aa, etc.
BUG=skia:
Change-Id: Id10f82e35a344247cab27e6d59a0dd2e11c9944d
Reviewed-on: https://skia-review.googlesource.com/9051
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't null out vertex's fPrev and fNext ptrs during
MonotonePoly::emit(); list_insert() will do it for us.
Don't normalize the tangent returned by get_unit_normal() to unit
length, since we can do the dot product comparison without it.
Copy Lines where possible, rather than recomputing them.
Change-Id: I733b00dd9d9d493313ac9a1c71aac0b708e78201
Reviewed-on: https://skia-review.googlesource.com/9047
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
|
|
|
|
|
|
|
|
|
| |
No need for it, since sweep_gt(a, b) == sweep_lt(b, a).
Change-Id: I9244687845530a8e11673c5360d9ac700933baa0
Reviewed-on: https://skia-review.googlesource.com/8987
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Perform boundary simplification and meshing inline with extraction.
Removed EdgeList::fNext (don't need to concatenate edge lists).
Removed new_contour() (don't need to heap-allocate them either).
BUG=skia:
Change-Id: I0f89bad105c03f3021b0d2f021064f408a361b59
Reviewed-on: https://skia-review.googlesource.com/8794
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change comparison functions to perform the common case first (a.fX > b.fX),
and the uncommon case (a.fX == b.fX) after the short-circuit.
Change Comparator to switch on a direction enum instead of using function
pointers.
Inline sorted_merge() and front_back_split() into merge_sort(), and template
it on the comparator function, so it instantiates two versions. This
is even faster (but costs us some code bloat of course).
BUG=skia:
Change-Id: I45a2376492240ed7e0552ca2aed75e303e918bc6
Reviewed-on: https://skia-review.googlesource.com/8791
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Invert some math to remove a negation.
Don't keep a persistent count in EdgeList; we'll test for degenerate
boundaries in boundary_to_aa_mesh().
Make connect() use the top/bottom ordering that new_edge has already
done for us.
Don't add the an edge to the same poly twice when it's easily detectable.
Remove some superfluous variables and intialization.
BUG=skia:
Change-Id: I0efd9ec385d6dfec8950b7acfc6dd25572f667b5
Reviewed-on: https://skia-review.googlesource.com/8784
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of using a full tessellate() pass, which allocates Polys,
MonotonePolys, etc. It's faster to simply accumulate the winding number
in the left-adjacent edge, and use that to remove non-boundary edges
(edges for which apply_fill_type() returns the same value on either
side of the edge).
This gives ~4-5% boost on MotionMark Fill Shapes.
Change-Id: I66bd4248ace01a8c35abd99519f4c455f936e5e5
Reviewed-on: https://skia-review.googlesource.com/8782
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SkArenaAlloc destructor was showing up as hot in profiling,
especially on Linux. The reason is that it was being used
incorrectly: the size estimate was being used as the chunk size. It
turns out that the best performance seems to be achieved with no
initial allocations and a fixed chunk size of 16K, as the CPU path
renderer does.
Also remove some unused code.
(This is a partial re-land of https://skia-review.googlesource.com/c/8560/)
TBR=bsalomon@google.com
Change-Id: I277eb1a6e5718a221974cd694c8a7e481e432ca6
Reviewed-on: https://skia-review.googlesource.com/8561
Reviewed-by: Stephen White <senorblanco@chromium.org>
Commit-Queue: Stephen White <senorblanco@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit e595bbfba6e7dcdda0d7d700343e9d814a406771.
Reason for revert: Breaking roll into Chromium.
virtual/gpu/fast/canvas/canvas-arc-circumference-fill.html
virtual/gpu/fast/canvas/canvas-ellipse-circumference-fill.html
https://build.chromium.org/p/tryserver.blink/builders/linux_trusty_blink_rel/builds/5170
https://storage.googleapis.com/chromium-layout-test-archives/linux_trusty_blink_rel/5170/layout-test-results/results.html
Original change's description:
> GrTessellator (AA): Performance tweaks and cleanup.
>
> The SkArenaAlloc destructor was showing up as hot in profiling,
> especially on Linux. The reason is that it was being used
> incorrectly: the size estimate was being used as the chunk size. It
> turns out that the best performance seems to be achieved with no
> initial allocations and a fixed chunk size of 16K, as the CPU path
> renderer does.
>
> Also, allocate the bisectors used for edge inversions on the
> stack, not the heap. And remove some unused code.
>
> BUG=skia:
>
> Change-Id: I754531c753c9e602713bf2c8bb5a0eaf174bb962
> Reviewed-on: https://skia-review.googlesource.com/8560
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Stephen White <senorblanco@chromium.org>
>
TBR=bsalomon@google.com,senorblanco@chromium.org,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Change-Id: I3cf6495c7345b6e6a79c2cb3a21dc6df0eed122f
Reviewed-on: https://skia-review.googlesource.com/8605
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SkArenaAlloc destructor was showing up as hot in profiling,
especially on Linux. The reason is that it was being used
incorrectly: the size estimate was being used as the chunk size. It
turns out that the best performance seems to be achieved with no
initial allocations and a fixed chunk size of 16K, as the CPU path
renderer does.
Also, allocate the bisectors used for edge inversions on the
stack, not the heap. And remove some unused code.
BUG=skia:
Change-Id: I754531c753c9e602713bf2c8bb5a0eaf174bb962
Reviewed-on: https://skia-review.googlesource.com/8560
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When sanitizing contours, if the first and last vertices coincide,
continue with the previous vertex, not the next vertex, since we
may otherwise exit prematurely. Also, round the last vertex before
entering the loop, just in case it coincides with the first.
Add a test case to exercise the above, and another one which exercises
the intruding-vertex workaround.
BUG=691593
Change-Id: Ic28a9308a21164d185edef0ee6fbc29b40742149
Reviewed-on: https://skia-review.googlesource.com/8364
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephen White <senorblanco@chromium.org>
|
|
|
|
|
|
|
|
|
| |
TBR=ethannicholas@google.com
Change-Id: I2efcbe540a2bdc42b8c2f0a675a42fe9e9ed717d
Reviewed-on: https://skia-review.googlesource.com/8383
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Herb Derby <herb@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Long description, but actually quite a small change.)
This is the first change inspired by the "straight skeleton" algorithm.
This algorithm gives us a mental model to describe the edge-antialiasing
problem: consider the shape as walls of a house, the outer alpha
geometry is a 45-degree "roof" up to a flat top at a height of 1.0
(the filled interior). The faces of the sloping roof join at the
bisectors between the inner and outer points.
When the shape being drawn is sufficiently thin, there should be no flat
roof, and the sloping roof meets at an edge (the straight skeleton).
This patch detects cases where an edge inverts on stroking, which
indicates that the flat roof has turned inside out, and should be
reduced to a point instead. The model above describes what to do:
follow down the "roof" along the bisectors to their intersection.
This is the point to which an inverted edge should be collapsed.
Fortunately, the bisector edges are easy to compute: they're the
connector edges joining inner and outer points. Linearly interpolating
the distance from the top to the bottom point gives the alpha we
should use to approximate coverage.
Now that we are correctly handling inversions, bevelling outer edges
is no longer necesary, since pointy outer edges won't cause nasty
opaque artifacts.
A couple of other quality improvements: on intersection, always lerp
the alpha of connector edge, even if the opposite edge is an inner edge
(later, when these edges are collapsed, we need this value to compute
the correct alpha). Fix the case where an intruding outer vertex
intersects exactly with an inner edge by maxing its alpha with the
computed value in check_for_intersection(). Finally, we also no longer
round off the intersections produced by Line::intersect(), since it
introduces a loss of quality with no measurable performance benefit.
Change-Id: I6fd93df3a57fffc0895e8cb68adbdba626ded0f1
Reviewed-on: https://skia-review.googlesource.com/8028
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephan White <senorblanco@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some regions were being incorrectly filled due to setting
connector edges winding to zero *after* merging collinear edges.
This would cause the merge to add the wrong winding value. Putting the
adjust before the call to merge_collinear_edges() fixes the problem.
Also, some pixels were not getting coverage due the inner edge being
+1 winding. Using -2 winding for inner edges ensure the interior
regions are -1 winding, which gives coverage in more cases of
self-intersection. This required flipping the comparisons on the
intruding-vertices workaround.
BUG=skia:
Change-Id: I216fa3d30c196a6b7773637e48802f6572c993c7
Reviewed-on: https://skia-review.googlesource.com/7962
Commit-Queue: Stephan White <senorblanco@chromium.org>
Reviewed-by: Brian Salomon <bsalomon@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When path features are very close together, the outer contours can
overlap. This causes the connector edges (the ones joining the inner and
outer vertices) to intersect other edges. Lerping the alpha along the
connector edge gives us a good approximation of the coverage at that
point.
BUG=skia:
Change-Id: I56bcc570fc185344c5f84d11ef995d3940a08793
Reviewed-on: https://skia-review.googlesource.com/7701
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephan White <senorblanco@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code to handle acute outer angles in generated geometry was pretty
broken: it did a simple runnning average of consecutive acute vertices,
and didn't handle acute angles between the last and first edges.
Replaced it with something simpler that does proper bevelling for
angles less than 2.5 degrees.
This revealed a bug with thin path segments, exposed by the thinconcavepaths
test. This will be fixed by upcoming changes, but I've also dded a few more
test cases to make it clearer.
Change-Id: I23a628ab2e16acaab798c746a5fd87842cacbfab
Reviewed-on: https://skia-review.googlesource.com/7660
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephan White <senorblanco@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
simplify_boundary() was incorrectly comparing squared distances
against a non-squared constant. For .25 of a pixel, we need to
compare against 0.25 squared, or 0.0625.
This also includes a fix to get_edge_normal(), We were actually
returning edge "vectors", instead of edge normals. This wasn't
causing problems, since the error cancels itself out, but it's
confusing.
BUG=skia:
Change-Id: I0d50f2d001ed5e41de2900139c396b9ef75d2ddf
Reviewed-on: https://skia-review.googlesource.com/7043
Commit-Queue: Stephan White <senorblanco@chromium.org>
Reviewed-by: Brian Salomon <bsalomon@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When path features are exactly a pixel wide, the extruded inner edges
can become collinear and then be removed, since their winding is
zero. We need these edges to be preserved through triangulation,
otherwise opaque portions of the geometry can become transparent.
Since the simplify() pass can handle zero-winding edges just fine, the
the fix is to simply not remove them.
In addition, this changes refactors out disconnect() from all the calls
to remove_edge_above()/remove_edge_below(). It also renames the remaining
function erase_edge() (since it's now unconditional).
Add a new test to a new "thinconcavepaths" GM.
BUG=680260
NOTRY=true
Change-Id: I1d3a436c95a01c4d4ef5dc05503de4312677f65d
Reviewed-on: https://skia-review.googlesource.com/6902
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephan White <senorblanco@chromium.org>
|
|
|
|
|
|
|
|
|
| |
BUG=skia:
Change-Id: I1f0df58ffe79e439f92a8c1cd3c39812c32d039f
Reviewed-on: https://skia-review.googlesource.com/6743
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephan White <senorblanco@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Prefer VertexList to a bare Vertex*. Also fix some 100-col issues.
This should have no user-visible impact.
Change-Id: I8fa260d5417c9832256529c232f532e69238fca0
Reviewed-on: https://skia-review.googlesource.com/6502
Commit-Queue: Stephan White <senorblanco@chromium.org>
Reviewed-by: Brian Salomon <bsalomon@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use quads rather than triangles for the edge geometry. This allows
us to perform a simpler edge categorization (see below). It also
improves performance by reducing the number of edges processed during
the simplify and tessellate steps.
Label AA edges as three types: inner, outer, and connector. This
results in correct alpha values for intersected edges, even when
the top or bottom vertex has been merged with a vertex on edges
of different types.
Changed the "collinear edges" sample from the concavepaths GM for a
"fast-foward" shape, which more clearly shows the problem being fixed
here. (The collinearity from the "collinear edges" was actually being
removed earlier up the stack, causing the path to become convex and
not exercise the concave path renderers anyway.)
NOTE: this will cause changes in the "concavepaths" GM results, and
minor pixel diffs in a number of other tests.
Change-Id: I6c2b0cdb35cda42b01cf1100621271fef5be35b0
Reviewed-on: https://skia-review.googlesource.com/6430
Reviewed-by: Stephan White <senorblanco@chromium.org>
Commit-Queue: Stephan White <senorblanco@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d4b21552481a6d313dfa9bc14b624c9ec94b56ce.
Reason for revert: accidentally added some unwanted changes
Original change's description:
> Quality and performance fixes for AA tessellating path renderer.
>
> Use quads rather than triangles for the edge geometry. This allows
> us to perform a simpler edge categorization (see below). It also
> improves performance by reducing the number of edges processed during
> the simplify and tessellate steps.
>
> Label AA edges as three types: inner, outer, and connector. This
> results in correct alpha values for intersected edges, even when
> the top or bottom vertex has been merged with a vertex on edges
> of different types.
>
> Changed the "collinear edges" sample from the concavepaths GM for a
> "fast-foward" shape, which more clearly shows the problem being fixed
> here. (The collinearity from the "collinear edges" was actually being
> removed earlier up the stack, causing the path to become convex and
> not exercise the concave path renderers anyway.)
>
> NOTE: this will cause changes in the "concavepaths" GM results, and
> minor pixel diffs in a number of other tests.
>
> BUG=660893
>
> Change-Id: Ide49374d6d173404c7223f7316dd439df1435787
> Reviewed-on: https://skia-review.googlesource.com/6427
> Commit-Queue: Stephan White <senorblanco@chromium.org>
> Reviewed-by: Brian Salomon <bsalomon@google.com>
>
TBR=bsalomon@google.com,senorblanco@chromium.org,reviews@skia.org
BUG=660893
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I06a36e397645bfc42442a5a9e7c27328f6048ab9
Reviewed-on: https://skia-review.googlesource.com/6428
Commit-Queue: Stephan White <senorblanco@chromium.org>
Reviewed-by: Stephan White <senorblanco@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use quads rather than triangles for the edge geometry. This allows
us to perform a simpler edge categorization (see below). It also
improves performance by reducing the number of edges processed during
the simplify and tessellate steps.
Label AA edges as three types: inner, outer, and connector. This
results in correct alpha values for intersected edges, even when
the top or bottom vertex has been merged with a vertex on edges
of different types.
Changed the "collinear edges" sample from the concavepaths GM for a
"fast-foward" shape, which more clearly shows the problem being fixed
here. (The collinearity from the "collinear edges" was actually being
removed earlier up the stack, causing the path to become convex and
not exercise the concave path renderers anyway.)
NOTE: this will cause changes in the "concavepaths" GM results, and
minor pixel diffs in a number of other tests.
BUG=660893
Change-Id: Ide49374d6d173404c7223f7316dd439df1435787
Reviewed-on: https://skia-review.googlesource.com/6427
Commit-Queue: Stephan White <senorblanco@chromium.org>
Reviewed-by: Brian Salomon <bsalomon@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This class is already just an alias for std::unique_ptr<T[]>, so replace
all uses with that and delete the class.
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-ASAN-Trybot,Test-Ubuntu-Clang-Golo-GPU-GT610-x86_64-Debug-ASAN-Trybot
Change-Id: I40668d398356a22da071ee791666c7f728b59266
Reviewed-on: https://skia-review.googlesource.com/4362
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the screenspace AA tessellator, a path's fill types would be applied
twice: once when extracting contours, and then again when filling polys.
It was supposed to be forced to kWinding_FillType by the second call to
mesh_to_polys(), but for hysterical reasons this parameter is unused!
For kInverseWinding_FillType (the only mode where this actually caused a bug),
I unwittingly papered over the problem by reversing the outer contour for the
inverse fill types, and comparing against -1 instead of 1.
The better fix is to actually pass a winding mode of kWinding_FillType
to polys_to_triangles(), and remove the (ignored) param from mesh_to_polys().
Then we can pass a clockwise outer contour as before, and compare
against 1 instead of -1.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2404403003
Review-Url: https://codereview.chromium.org/2404403003
|
|
|
|
|
|
|
| |
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2405813003
Review-Url: https://codereview.chromium.org/2405813003
|
|
|
|
|
|
|
|
|
|
| |
There are cases where we need only a line equation, and not a full
Edge. Create a Line struct for this, and refactor Edge to use it.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2397963003
Review-Url: https://codereview.chromium.org/2397963003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an approach to antialiased concave path rendering
on the GPU without using MSAA. It uses GrTessellator to
extract boundary contours from the given path, then
inflates by half a pixel in screen space each direction,
then renders the result with zero alpha on the outer
contour and one alpha on in the inner contour. This
requires two passes through the tessellation code: one
to extract the boundaries, then one to tessellate the
result.
This gives approximately a 3X improvement on the IE
chalkboard demo in non-MSAA mode, a 30-40% improvement
on MotionMark's "Fill Paths", and a ~3X improvement on
MotionMark's "canvas arcTo segments".
It works best for large, simple paths, so there's currently
a limit of 10 verbs in the onCanDrawPath() check. This
dovetails nicely with the distance field path renderer's
support for small, detailed (and cached) paths.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1152733009
NOTRY=true
Review-Url: https://codereview.chromium.org/1152733009
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of https://codereview.chromium.org/1152733009/ )
Reason for revert:
Causing asserts in GLPrograms test on Mac.
Original issue's description:
> Screenspace AA tessellated GPU path rendering.
>
> This is an approach to antialiased concave path rendering
> on the GPU without using MSAA. It uses GrTessellator to
> extract boundary contours from the given path, then
> inflates by half a pixel in screen space each direction,
> then renders the result with zero alpha on the outer
> contour and one alpha on in the inner contour. This
> requires two passes through the tessellation code: one
> to extract the boundaries, then one to tessellate the
> result.
>
> This gives approximately a 3X improvement on the IE
> chalkboard demo in non-MSAA mode, a 30-40% improvement
> on MotionMark's "Fill Paths", and a ~3X improvement on
> MotionMark's "canvas arcTo segments".
>
> It works best for large, simple paths, so there's currently
> a limit of 10 verbs in the onCanDrawPath() check. This
> dovetails nicely with the distance field path renderer's
> support for small, detailed (and cached) paths.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1152733009
>
> Committed: https://skia.googlesource.com/skia/+/9992bdef8ae97b3e5b109d278ccfab84c66bcbf0
TBR=bsalomon@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review-Url: https://codereview.chromium.org/2299683002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an approach to antialiased concave path rendering
on the GPU without using MSAA. It uses GrTessellator to
extract boundary contours from the given path, then
inflates by half a pixel in screen space each direction,
then renders the result with zero alpha on the outer
contour and one alpha on in the inner contour. This
requires two passes through the tessellation code: one
to extract the boundaries, then one to tessellate the
result.
This gives approximately a 3X improvement on the IE
chalkboard demo in non-MSAA mode, a 30-40% improvement
on MotionMark's "Fill Paths", and a ~3X improvement on
MotionMark's "canvas arcTo segments".
It works best for large, simple paths, so there's currently
a limit of 10 verbs in the onCanDrawPath() check. This
dovetails nicely with the distance field path renderer's
support for small, detailed (and cached) paths.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1152733009
Review-Url: https://codereview.chromium.org/1152733009
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GrTessellator fix for doubly-added edges in
https://codereview.chromium.org/2259493002/ could leave
a MonotonePoly with zero edges. This is a problem for
Poly::addEdge(), which assumes that MonotonePolys always have
at least one edge. The fix is to move the check and early-out up to
Poly::addEdge(). This should also tighten up the vertex count.
(Unfortunately, the only repro I have for this issue is very
convoluted, and requires non-landed code.)
BUG=skia:5636
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2251643008
Review-Url: https://codereview.chromium.org/2251643008
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In rare cases, floating point error causes the tesselator to add the
same Vertex to more than one Poly on the same side. This was not a big
problem when we were allocating new vertices when constructing Polys,
but after https://codereview.chromium.org/2029243002 it causes more serious
issues, since each Edge can only belong to two Polys, and violating this
condition messes up the linked list of Edges used for left & right Polys
and the associated estimated vertex count.
The fix is to simply let the first Poly win, and skip that vertex for
subsequent Polys. Since this only occurs in cases where vertices are very
close to each other, it should have little visual effect.
This is also exercised by Nebraska-StateSeal.svg.
BUG=skia:5636
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2259493002
Review-Url: https://codereview.chromium.org/2259493002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we start a new MonotonePoly due to a handedness change, we don't need to
increase the vertex count, since that edge (and vertex) has already been
accounted for in the previous MonotonePoly.
This was not a correctness issue, but was causing us to allocate
extra vertices which would go unused.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2146063002
Review-Url: https://codereview.chromium.org/2146063002
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't add an edge if the bottom vertex was already added, or
if an island vertex has a left poly but no right poly.
(Sorry for the lack of test, but the only reduction I could create was still a huge path and only crashes in Chrome.)
BUG=617907
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2043873005
Review-Url: https://codereview.chromium.org/2043873005
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The vertices which are produced by stage 5 of the
tesselator are copied into the Polys and MonotonePolys it
produces. This is necessary because each vertex may have an
arbitrary valence, since it may participate in an arbitrary
number of Polys, so we can't use the vertex's prev/next
pointers to represent all the Monotones of which this
vertex may be a member.
However, each Edge can only be a member of two Polys (one
on each side of the edge). So by adding two prev/next
pointer pairs to each Edge, we can represent each Monotone
as a list of edges instead. Then we no longer need to copy
the vertices.
One wrinkle is that the ear-clipping stage (6) of the
tessellator does require prev/next pointers, in order to
remove vertices as their ears are clipped. So we convert
the edge list into a vertex list during Monotone::emit(),
using the prev/next pointers temporarily for that monotone.
This change improves performance by 7-20% on a non-caching
version of the tessellator, and reduces memory use.
Other notes:
1) Polys are initially constructed empty (no edges), but
with the top vertex, which is needed for splitting
Polys. Edges are added to Polys only after their bottom
vertex is seen.
2) MonotonePolys are always constructed with one edge, so
we always know their handedness (left/right).
MonotonePoly::addEdge() no longer detects when a monotone
is "done" (edge of opposite handedness); this is handled
by Poly::addEdge(), so MonotonePoly::addEdge() has no
return value.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2029243002
Review-Url: https://codereview.chromium.org/2029243002
|
|
|
|
|
|
| |
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1842753002
Review URL: https://codereview.chromium.org/1842753002
|
|
|
|
|
|
|
|
|
|
|
|
| |
This abstracts all vertex allocation out of GrTessellator via a VertexBuffer interface. This removes all GPU-related calls from GrTessellator.
It also factors vertex drawing into GrTessellatingPathRenderer::drawVertices(), and makes tessellate() (now draw() also responsible for drawing. This means the cache hit case is clearer as an early-out,
and storing into cache is done in draw() as well.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1776003002
Review URL: https://codereview.chromium.org/1776003002
|
|
|
|
|
|
|
|
|
|
| |
Implement a VertexList, and use it.
Rename insert<> -> list_insert<>.
Rename remove<> -> list_remove<>.
Remove some spurious returns.
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1771373002
Review URL: https://codereview.chromium.org/1771373002
|
|
|
|
|
|
|
|
| |
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1557083002
Committed: https://skia.googlesource.com/skia/+/8b05cb8a00bdb82e100f1ba74bf4de4a504cceea
Review URL: https://codereview.chromium.org/1557083002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
file. (patchset #8 id:240001 of https://codereview.chromium.org/1557083002/ )
Reason for revert:
broke valgrind bot
Original issue's description:
> Broke GrTessellatingPathRenderer's tessellator out into a separate file.
> GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1557083002
>
> Committed: https://skia.googlesource.com/skia/+/8b05cb8a00bdb82e100f1ba74bf4de4a504cceea
TBR=bsalomon@google.com,joshualitt@chromium.org,senorblanco@chromium.org,ethannicholas@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1570503002
|
|
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1557083002
Review URL: https://codereview.chromium.org/1557083002
|