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>
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>
* Rename TFlagsMask<> to Mask<>
* Make Mask<> implicitly convertible to bool
* Rename SKGPU_MAKE_BITFIELD_CLASS_OPS to SKGPU_MAKE_MASK_OPS
* Remove the macro for non-class enums
Change-Id: I86059335d731f34c9c9c20a4cd6d5491543aa3b1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/456816
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Saves a few LOC and seems like a nice cleanup.
Change-Id: Id2bb2196b3d1451a1259758d8e0052741ec60f52
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457118
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Previously, we used special cases with `When` and unused scratch
variables to simulate passing in a variable-length array of uniforms.
Now we can use uniform arrays directly.
Change-Id: Iadbcdeb260d1245105eb785bc901b95a6edfeeca
Bug: skia:8401
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/456928
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
As DSLWriter evolved, it ended up performing two unrelated duties:
1. Holding per-thread state which is referenced throughout SkSL
(including non-DSL code)
2. DSL-specific utility functions
There's no reason for those to be contained in the same class, and
there's also no reason the per-thread state should be held in a
DSL-specific class. This breaks out an SkSL::ThreadContext class to hold
the state info, leaving the DSL utility functions behind in DSLWriter
(which should perhaps be renamed, but that's a job for a future CL).
Change-Id: Iccd45314bd9b37d4a1d3e27920e32a50c0b07d7c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/456736
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
This is a reland of e023608611
I have expanded the scope of this CL because having multiple
versions of the same code was confusing me.
All updatable functionality has been moved to SkTransformShader.
I made SkUpdatableShader implement the SkStageUpdater allowing
SkTransformer to act as both types of updater.
Original change's description:
> change matrix_2x3 to row-major
>
> Change-Id: Id25b3875f54f359bac90b6d3a7695287fc108b64
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/456467
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Herb Derby <herb@google.com>
Change-Id: I3326d8ea2c6fa9dabca8021a746600b4649933e7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/456638
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
With this change it should now be safe to start using Proxys and Textures
everywhere. There is no caching the Proxys/Textures will live as long as
someone holds a ref.
Bug: skia:12466
Change-Id: I3c657b65b44b9dca0a77a255d6a4fc89e3862124
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/456916
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Change-Id: Ibb8695917d0a8ff43467542ee7a7b36f573513f8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/456798
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This is basically GrShape except that I removed some of the API that
GrStyledShape used. I also changed the set of types that Shape can
represent to be better match what I imagine our final set will be in
graphite: {empty,point,line,rect,rrect,path,arc}
-> {empty,rect,rrect,path,convex-polygon}
The convex polygon is used to store points and lines as well. I also
imagine that it will subsume the need for migrating GrQuad over.
I'm doing this on its own in preparation for moving the ClipStack over
and consolidating the draw handling in Device/DrawList, all of which
get a lot easier if there is a single type that stores the geometry.
For the first milestone, actual rendering will still likely use
Shape::asPath() for the path renderer, but it's not a lot of extra work
to preserve the logical type at the high level, so may as well do that.
There are a few functions internal to Shape that still need to be
implemented (converting a path to a list of vertices, and doing point
containment), but those can come in a later CL.
Bug: skia:12466
Change-Id: I1040c54e3b8004f3bc1767d72ded60b572b39596
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/456257
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Change-Id: I08717dd9e9ad20a18a623e06f0c66a0f697effa4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/456796
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
