This approach has a little bit less redundancy than before.
Change-Id: Ibb1b71263acf28ca09c5be9492c100f1da46db69
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458460
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
We can offset into the color and position arrays by just incrementing
them. We don't need to maintain a separate offset value.
Change-Id: Ic41d5252054f7c167a5b90d3ecef9fd8672fa803
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458459
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This extracts the divide used in SkImageBlurFilter.cpp, and
encapsulates it into ScaledDividerU32. It generates results that
are with in +/- 1 of the rounded answer generated by doubles.
I have added hand coded implementations for sse and for neon to
hopefully to avoid code generation problems.
Bug: skia:12522
Change-Id: Ia7372d45895c799f69f8c0fd9fdea5efac321139
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458216
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This is a reland of e2fa96ba4a
Original change's description:
> Create looping binary-search gradient colorizer.
>
> This allows us to dramatically increase the number of gradient stops
> before falling back to sampling from a texture (which smears hardstops
> and shows artifacts in extreme edge cases). The analytic colorizer
> doesn't suffer from these artifacts and blurriness effects.
>
> In nanobench, this change comes at a performance penalty for some tests:
> http://go/paste/6302350793768960
>
> The texture path might have a bit of an unfair advantage here, if the
> gradient texture can just be uploaded once and reused from the cache
> repeatedly. Presumably the setup cost of texture generation and upload
> is fairly expensive, but nanobench is testing just the steady-state
> render performance. In comparison, the analytic colorizer doesn't have
> a large setup cost.
>
> Change-Id: I71baa539a2c7f9e311ef8125de4ede2fdbf0c2d0
> Bug: skia:8401
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457499
> Auto-Submit: John Stiles <johnstiles@google.com>
> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Bug: skia:8401
Change-Id: I389f79909bc1424909481b06d70db285b55648fe
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458277
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Working to remove some of the specialized SkPaintToGrPaintXXX methods.
Bug: skia:11942
Change-Id: I6069319f2b3fa7131cac39f17bc7bc1bd994241f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/456959
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This test page exercised some cases in our gradient code that were
not hit by any of our existing tests in Skia. (Specifically, simple
gradients with large numbers of redundant stops that can be optimized
away.)
Change-Id: If3309487ddc3d4057e2f160ae3bd319ea356669a
Bug: skia:8401
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457658
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
and add a Release M1 test bot
Bug: skia:12466
Change-Id: Id7c7c2e01764127c5ff92be7f636aadb9022f582
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457897
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Add GM repros and up triangulation verb count to match chromium's define
The GMs draw incorrectly in (base->p2) with the updated verb count, but
would draw fine w/o the increased verb count because a different path
renderer would be chosen.
This fixes a latent bug that was in the edge splitting code of the
triangulator that was exposed by https://skia-review.googlesource.com/c/skia/+/432196
Before that CL, intersections of two lines would be clamped to one of the
4 vertices of the 2 segments. In the CL linked, the clamping was adjusted
to clamp X and Y axes separately, so it increased the chance that a
clamped intersection would have its X or Y coord equal to line's vertex
but differ along the other coord (when they both equaled, they were
considered coincident and splitting that edge did nothing).
Splitting an edge at its intersection was intended to split (p0 to p1)
into new lines (p0 to v) and (v to p1) where p0 < v < p1 according to the
vertical or horizontal sorting that was imposed on the mesh. For a given
line segment and a clamped vertex, there are 8 ways the intersection
could be clamped (4 edges and 4 corners). If the edge has a positive
non-zero slope, a zero slope, or an infinite slope, in all cases the
clamped intersection will be sorted correctly and satisfy p0 < v < p1.
However, if the edge has negative slope
vertical: p0.y<p1.y and p0.x>p1.x,
horizontal: p0.x<p1.x and p0.y<p1.y
then intersections snapped to the primary sorting axis will be out of
order and produce a split such that v < p0 < p1 or p0 < p1 < v. This
was already detected, but it didn't update the winding of the new edge
to preserve the original winding from p0 to p1.
In these out-of-order cases, the intersection point is the top of both
the new and old edge, or the bottom of both the new and old edge. This
means that winding "top to bottom" on the new edge would go in the
opposite direction as the original winding from p0 to p1. Flipping the
winding on the new edge preserves the intended winding of the contour
while still allowing the edges/vertices to be sorted consistently.
This showed up as large gradients in the AA triangulator because w/o the
winding adjustment, the winding flip at the new edge would confuse the
border extractor that was used to compute insets and outsets for the 1px
coverage ramp. It would then use edges that were normally unrelated to
each and declare their line intersections as the "interior" with full
coverage. Obviously these could be anywhere so the 1px coverage ramp
would get smeared across that shape.
Bug: chromium:1257515
Change-Id: I015d6b4767db352e3eecfc53047958e74320268d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458057
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
SkSL treated these two functions as distinct, even though they are not:
void func(in float x);
void func(float x);
The `in` modifier on a function parameter is the default state, making
these two prototypes functionally identical. We now strip off an `in`
modifier on a function definition. This gives us three potential states
for each param: nothing (meaning `in`), `out`, and `inout`.
Change-Id: Id2acb53ecaca98f86a7f6a83e0b9a375f9abe2b8
Bug: skia:12525
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458257
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit e2fa96ba4a.
Reason for revert: fillrect_gradient.html assert
Original change's description:
> Create looping binary-search gradient colorizer.
>
> This allows us to dramatically increase the number of gradient stops
> before falling back to sampling from a texture (which smears hardstops
> and shows artifacts in extreme edge cases). The analytic colorizer
> doesn't suffer from these artifacts and blurriness effects.
>
> In nanobench, this change comes at a performance penalty for some tests:
> http://go/paste/6302350793768960
>
> The texture path might have a bit of an unfair advantage here, if the
> gradient texture can just be uploaded once and reused from the cache
> repeatedly. Presumably the setup cost of texture generation and upload
> is fairly expensive, but nanobench is testing just the steady-state
> render performance. In comparison, the analytic colorizer doesn't have
> a large setup cost.
>
> Change-Id: I71baa539a2c7f9e311ef8125de4ede2fdbf0c2d0
> Bug: skia:8401
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457499
> Auto-Submit: John Stiles <johnstiles@google.com>
> Commit-Queue: Michael Ludwig <michaelludwig@google.com>
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Bug: skia:8401
Change-Id: I4054d075d9322b9d9a6d3c7383be9b115ad20cfa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458276
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bug: skia:12515
Change-Id: I8db3501c129d93fc1eb822c90840119a7a7f2b4b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457478
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
This allows us to dramatically increase the number of gradient stops
before falling back to sampling from a texture (which smears hardstops
and shows artifacts in extreme edge cases). The analytic colorizer
doesn't suffer from these artifacts and blurriness effects.
In nanobench, this change comes at a performance penalty for some tests:
http://go/paste/6302350793768960
The texture path might have a bit of an unfair advantage here, if the
gradient texture can just be uploaded once and reused from the cache
repeatedly. Presumably the setup cost of texture generation and upload
is fairly expensive, but nanobench is testing just the steady-state
render performance. In comparison, the analytic colorizer doesn't have
a large setup cost.
Change-Id: I71baa539a2c7f9e311ef8125de4ede2fdbf0c2d0
Bug: skia:8401
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457499
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
This will be used to allow us to safely make shaders which index into
arrays using expressions which cannot be determined at compile-time.
(ES2 cannot do this.)
Change-Id: Id291aa69bfb7cbc366de17013ee19a9061db3bf2
Bug: skia:8401
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457196
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This is step 1 of a less surgical method of specializing vectors with
constructors and swizzles.
Bug: skia:12515
Change-Id: I4d65ad595387b35fa74df8564c73952e0a8b681c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457477
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
This is in prep for compiling with -std=c++14 and -Wno-c++17-extensions
when building with clang. Chrome has encountered problems with
third_party headers that are included both in Skia and other Chrome
sources that produce different code based on whether preprocessor macros
indicate a C++14 or C++17 compilation.
In C++17 they are already inline implicitly. When compiling with C++14
we can get linker errors unless they're explicitly inlined or defined
outside the class. With -Wno-c++17-extensions we can explicitly inline
them in the C++14 build because the warning that would be generated
about using a C++17 language extension is suppressed.
We cannot do this in public headers because we support compiling with
C++14 without suppressing the C++17 language extension warnings.
Bug: chromium:1257145
Change-Id: Iaf5f4c62a398f98dd4ca9b7dfb86f2d5cab21d66
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457498
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Bug: skia:12466
Change-Id: I401a185d818a964327d323b9ebcd0850ec0b1c9b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457318
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
In addition to single line (point) text, AE also supports path layout
for paragraph text.
At a high level, the paragraph box top is mapped to the path (following
alignment rules), and each glyph is displaced along its path positioning
vector, post orientation.
The main difference compared to point text, is that the distance on path
is based on the fragment position relative to the paragraph left edge.
The paragraph box also plays a role in alignment: left/center/right
aligns with path start/mid/end.
This includes a tangential optimization: instead of validating cached
contour data in each PathInfo::getMatrix() call, we only check once at
a higher level (onSync) -- to avoid performing a shape vector comparison
for each fragment.
Change-Id: I2c31ce3b0a525a3cd2d4525abcf88d5fc943bb6e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457656
Commit-Queue: Florin Malita <fmalita@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Jorge Betancourt <jmbetancourt@google.com>
"Perpendicular To Path" and "Reverse Path" are animatable in AE, but
used to be exported as static props. Bodymovin is being updated to
export them as animatable now.
Change the parser to handle both cases.
Change-Id: If2fea2a37af7ec6af5ac07c24cfb533bff5e03ca
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457736
Auto-Submit: Florin Malita <fmalita@chromium.org>
Commit-Queue: Jorge Betancourt <jmbetancourt@google.com>
Reviewed-by: Jorge Betancourt <jmbetancourt@google.com>
This GM presents different gradients with an increasing number of
hardstops, from 1 to 100.
Change-Id: I1c279c6ea1a25f9785001aa29db632547a38ab68
Bug: skia:8401
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457437
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This loop was not checking the entire range of gradient intervals.
In practice this is probably not a big deal, since it only affects a
few devices, and only matters for very complex gradients.
Change-Id: I735fcace013633c2bb14da65c4f573a3ef837d06
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457497
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This reverts commit 01b02956c7.
Reason for revert: Codegen regressions
Original change's description:
> Add convenient "xyzw" accessors and swizzles to skvx
>
> Change-Id: Ic300285d10679a4e34190ab7b6b08bd1f6d80330
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/454309
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
> Commit-Queue: Chris Dalton <csmartdalton@google.com>
Bug: skia:12515
Change-Id: Id853e4d9e25c6d2ae622668ef064e1b2b078b824
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457476
Auto-Submit: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
These changes shouldn't directly affect the results at all, but make the
logic slightly more modular and reusable. This will be helpful in
followup CLs, which add a new gradient colorizer type and will share a
lot of this logic.
Change-Id: Ica7ccfe10877fcd69dbfa45da3e77874a0414120
Bug: skia:8401
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457297
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Makes the Make() method consistent with other methods by passing in
Gpu, and adds hooks for command buffer tracking.
Bug: skia:12466
Change-Id: If93c2126b1296dcbf788b5471916051fe90dafdf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457319
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
The benefits of this method (if any) are not measurable on any
microbenchmarks that use it profusely. I have also seen it slow down
performance by not allowing the compiler as much freedom in optimizing.
Change-Id: I23500323a08ffdccedc494f30876146574eb31b3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457186
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Before we get too excited, this does not use CanvasKit.
What this does add is an origin-trial token so we can
more easily demo our progress on *.skia.org and test
locally using localhost:8123 (which is the default
if you run make local in //demos.skia.org)
To view this locally, I started chrome (stable 94) with
--enable-features=Vulkan --enable-unsafe-webgpu
Enabling the Vulkan was the advice of
https://web.dev/gpu/#browser-support
The second flag make sure the whole stack also uses Vulkan.
Change-Id: Ia1838352a46387b0b79e353601a32c859f6911c1
Bug: skia:12512
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457316
Reviewed-by: Brian Salomon <bsalomon@google.com>
Current limitations:
-- single-line only (no paragraph box support)
-- "Force Alignment" not supported
-- tracking animators not supported
Change-Id: I4072f1d8280032787c6db7e8b47d6f55be43bddb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/456237
Commit-Queue: Florin Malita <fmalita@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Change-Id: I3a159fb4f96a4f8071efb8e88bbe097e0fedd88f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457296
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
