Now that hardware tessellators chop, support raw triangles, and can
handle any path, we don't need complicated logic anymore to determine
when we can't use them. This CL simplifies the criteria for selecting
a tessellation algorithm and adds a fAlwaysPreferHardwareTessellation
context option to override it.
Bug: skia:10419
Change-Id: I8492e8f285ff27eb9d0dd6b1e9817dbeeb386c63
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/411496
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
These paths trigger cases where we know we must add the inner join
geometry.
Bug: skia:11964
Change-Id: I9c66baf6a9f9fda55911651adae01ba1a22b3aa2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/408156
Commit-Queue: Tyler Denniston <tdenniston@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Bug: chromium:1210557
Change-Id: Ib41cbf3236abdbb105ce818756505ff40c868cf1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/411301
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Makes the code from yuv_splitter reusable and able to produce subsampled
planes.
Bug: chromium:1210557
Change-Id: Icce112658bbdb866c3ecb9dcff1a5e8d0d30135a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/411297
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Other than GMs, there is exactly one use of matrix-sampling
(GrMatrixEffect). It is always uniform (not literal or an
expression containing a uniform). The uniform always has the
same name. Bake these simplifications in, which also shrinks
SampleUsage quite a bit.
Change-Id: I0d5e32069d710af475ccc1030e2988c5fc965a98
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/411296
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Tests mirrors (where the src and dst rects are equal, but local coords
have been flipped), and perspective (which is just generally hard).
Bug: skia:11994, skia:12015
Change-Id: Ic57b004d2741e0e713fed17825071c5c9cf63486
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/410000
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Auto-Submit: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
- most of the small diffs are because I moved GrWangsFormula.h out
of the tessellate/ directory and into the geometry/ directory since
it's more general than HW tessellation.
The previous implementation was based on the heuristic that the distance
from the true curve to the line segment would be divided by 4 every time
the curve was recursively subdivided. This was a reasonable
approximation if the curve had balanced curvature on both sides of the
split. However, in the case of the new GM's curve, the left half was
already very linear and the right half had much higher curves.
This lead to the approximation reporting fewer points than required.
Theoretically, those few points that weren't utilized by the left half
of the curve could have been made available to the right half, but the
implementation of that would be tricky.
Instead, it now uses Wang's formula to compute the number of points.
Since recursive subdivision leads to linearly spaced samples assuming it
can't stop early, this point count represents a valid upper bound on
what's needed. It also then ensures both left and right halves of a
curve have the point counts they might need w/o updating the
generation implementations. However, since the recursive point
generation exits once each section has reached the error tolerance, in
scenarios where the prior approximation was reasonable, we'll end up
using fewer points than reported by Wang's. Hopefully that means there
is negligible performance regression since we won't be increasing
vertex counts by that much (except where needed for correctness).
Bug: skia:11886
Change-Id: Iba39dbe4de82011775524583efd461b10c9259fe
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405197
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Change-Id: I674f038600afd6d49316c1ece515941ee5579068
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/406939
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
* Make sure to actually use hardware tessellation on the *_tess_segs_5
gms. These had started using the fixed count tessellator.
* Add a trickycubicstrokes version with round caps to test upcoming
coverage AA modes.
* Make the colors more appealing since I spend all day looking at
these gms.
Bug: skia:10419
Change-Id: Ie7ab4e936ffa3ccffe4999e51fac4c3d4ab97f06
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/406976
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
This effectively reverts a80ce1a36d,
and goes back to using SkMakeSpan (which works in C++14).
Change-Id: Iaa63c86b5acaadbdd60588b0a5c703820e810770
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/406938
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This makes them easier to integrate with other shader code than having
them in GrGeometryProcessor.
Bug: skia:11396
Change-Id: I572348b8484ae46e00ac15832cd818390d536441
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/406437
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
This is a reland of adadb95a9f
... adds a temporary workaround for some Android framework code.
Original change's description:
> Better first-class shader & color filter support in runtime effects
>
> This does a few things, because they're all intertwined:
>
> 1) SkRuntimeEffect's API now includes details about children (which Skia
> stage was declared, not just the name). The factories verify that the
> declared types in the SkSL match up with the C++ types being passed.
> Today, we still only support adding children of the same type, so the
> checks are simple. Once we allow mixing types, we'll be testing the
> declared type against the actual C++ type supplied for each slot.
> 2) Adds sample variants that supply the input color to the child. This
> is now the only way to invoke a colorFilter child. Internally, we
> support passing a color when invoking a child shader, but I'm not
> exposing that. It's not clearly part of the semantics of the Skia
> pipeline, and is almost never useful. It also exposes users to
> several inconsistencies (skbug.com/11942).
> 3) Because of #2, it's possible that we can't compute a reusable program
> to filter individual colors. In that case, we don't set the constant
> output for constant input optimization, and filterColor4f falls back
> to the slower base-class implementation.
>
> Bug: skia:11813 skia:11942
> Change-Id: I06c41e1b35056e486f3163a72acf6b9535d7fed4
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401917
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:11813 skia:11942
Change-Id: I2c31b147ed86fa8c4dddefb7066bc1d07fe0d285
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404637
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit adadb95a9f.
Reason for revert: breaking android
Original change's description:
> Better first-class shader & color filter support in runtime effects
>
> This does a few things, because they're all intertwined:
>
> 1) SkRuntimeEffect's API now includes details about children (which Skia
> stage was declared, not just the name). The factories verify that the
> declared types in the SkSL match up with the C++ types being passed.
> Today, we still only support adding children of the same type, so the
> checks are simple. Once we allow mixing types, we'll be testing the
> declared type against the actual C++ type supplied for each slot.
> 2) Adds sample variants that supply the input color to the child. This
> is now the only way to invoke a colorFilter child. Internally, we
> support passing a color when invoking a child shader, but I'm not
> exposing that. It's not clearly part of the semantics of the Skia
> pipeline, and is almost never useful. It also exposes users to
> several inconsistencies (skbug.com/11942).
> 3) Because of #2, it's possible that we can't compute a reusable program
> to filter individual colors. In that case, we don't set the constant
> output for constant input optimization, and filterColor4f falls back
> to the slower base-class implementation.
>
> Bug: skia:11813 skia:11942
> Change-Id: I06c41e1b35056e486f3163a72acf6b9535d7fed4
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401917
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
TBR=mtklein@google.com,bsalomon@google.com,brianosman@google.com
Change-Id: I94ba57e73305b2302f86fd0c1d76f667d4e45b92
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:11813 skia:11942
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404117
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
This does a few things, because they're all intertwined:
1) SkRuntimeEffect's API now includes details about children (which Skia
stage was declared, not just the name). The factories verify that the
declared types in the SkSL match up with the C++ types being passed.
Today, we still only support adding children of the same type, so the
checks are simple. Once we allow mixing types, we'll be testing the
declared type against the actual C++ type supplied for each slot.
2) Adds sample variants that supply the input color to the child. This
is now the only way to invoke a colorFilter child. Internally, we
support passing a color when invoking a child shader, but I'm not
exposing that. It's not clearly part of the semantics of the Skia
pipeline, and is almost never useful. It also exposes users to
several inconsistencies (skbug.com/11942).
3) Because of #2, it's possible that we can't compute a reusable program
to filter individual colors. In that case, we don't set the constant
output for constant input optimization, and filterColor4f falls back
to the slower base-class implementation.
Bug: skia:11813 skia:11942
Change-Id: I06c41e1b35056e486f3163a72acf6b9535d7fed4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401917
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This adds an explicit DeclareGlobal call, which must now be called for
variables that were previously implicitly global.
Change-Id: Iaf838880d1033ee52aac9246e31e3bda9a3b36f0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402399
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Simplifies SampleUsage quite a bit (no need to track multiple kinds of
sampling, variable matrices don't exist any more, etc...).
Change-Id: I58b8de7218d00c4d882d2650672e5fe01892a062
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402177
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Replace with two methods in SkGr.h that make cached/uncached texture
proxies from SkBitmap. Move code that makes a GrFP from the proxy
to SkImage_Raster::asFragmentProcessor.
Bug: skia:11877
Change-Id: I51a0ae687561be9b0e44b98ee50f171e42476d94
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401920
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
For GPU:
Handling a blob that moved around in perspective reused cached
information incorrectly. Always recalculate the sub run
information when drawing perspective.
For Bitmap:
Make color emoji draw correctly.
Testing:
Add a GM that draws a single text blob in multiple different
perspective orientations.
Bug: skia:10473
Bug: skia:8914
Change-Id: I945e3326804ec47bf8cbca0e3cf4a17afc9ba5f0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/400598
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Bug: skia:11869
Change-Id: Ia6693cd765b5bd2acda147798b79a05ec31bbce5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401436
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
In the new GM, the left and right portions of the path have a shared
vertex. The two edges leaving that vertex vertically towards the bottom
of the image are nearly parallel but the right edge has a steeper slope.
This leads to two sources of self intersections. The outset vertices
for the left and right sides intersect, which converts some of those
edges into "connecting" edges and removes others (preventing double
hitting of pixels). However, these outset but now "connecting" edges
from the right side also overlap with the inset vertices of the left
shape, requiring additional vertex splitting and connecting edge
creation.
The old alpha logic when one of the intersecting edges was a connecting
edge was to use its interpolated alpha value. In this case, since the
connecting edge originated from two outset vertices, its end point
alphas were 0 and the split alpha became 0, even though the other
intersecting edge was an interior edge.
This CL flips the logic around and ensures that any split vertex that
is on the interior edges remains fully opaque, any vertex that is
fully on the exterior remains fully transparent, and anything else
uses the max of the interpolated alphas (equivalent to the old
logic when one edge was connecting and one was exterior, but is more
accurate if somehow we get two connecting edges intersecting).
Bug: skia:11859
Change-Id: I85d2d54a8833e3c9da2fdd1a4f3a0513119730b9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/400596
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Bug: skia:11813
Change-Id: I9748a2806fe4636111fbb5740a3ebdb0814cfc35
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401018
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Mixed samples is no longer relevant for Ganesh. DMSAA and the new
Ganesh architecture both rely on full MSAA, and any platform where
mixed samples is supported will ultimately not use the old
architecture.
Change-Id: I5acc745010e090ef26310d92ec6240be2cd494cf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/399837
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Add a drawGlyphs to SkCanvas that takes SkRSXform instead of
positions. Update buffer sizing calculations to take
SkRSXform buffers into account.
Change-Id: I14529088199dcd0b1ae78b4605e1ba77fec2000e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/399096
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Herb Derby <herb@google.com>
The old factory is deprecated. The new ones do stricter checking on the
signature of main and calls to sample, and include checks at effect
creation-time that the SkSL is valid for the requested stage.
Bug: skia:11813
Change-Id: Ibd15a6f90e74bdc9c2352d3dc61b6682f626f413
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/397477
Reviewed-by: Florin Malita <fmalita@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Also take SkImageInfo in SkImage_GpuBase.
Change-Id: Ie6d71a9a4a3740b9acc0faae72df2796e9a0e567
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/398230
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This ensures we don't lose the original SkSurfaceProps when creating
image filters, etc.
Bug: skia:11396
Change-Id: I6b412361c1005138278a1396faa7f7e069ec7eb2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/397291
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
This was an experimental feature. It worked (but only the GPU backend).
It was never adopted or used by anyone, to my knowledge. It's a large
amount of code, and a strange corner of SkSL for users to stumble into.
Bug: skia:10680
Change-Id: I0dda0364bce7dbffa58c32de4c7801ec2a6bc42e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/398222
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
As explained, this is *very* conservative. It only works when the child
is sampled from within main, and using a direct reference to the coords
parameter. If that parameter is ever modified (even after being used),
the optimization doesn't happen. For most cases, this is fine.
Bug: skia:11869
Change-Id: Ia06181730a6d07e2a4fe2de4cc8e8c3402f0dc52
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/397320
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
These are rounded rectangles whose corners are superellipses instead
of ovals. This builds on a lot of work done by zakcohen@google.com to
define a consistent, visually appealing shape that can be used
reliably in the Android UI.
Change-Id: I97fde7be870152c9ee776fde53118019d0caa251
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/397416
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
More details are in the bug, but the specific test case gets an
overlap region in the AA outset geometry for the left and right shapes.
Additionally, the mitered outset for the left shape is collinear with
the bottom of the right shape, so the winding of exterior edge of
the overlap region is updated to +2.
When determining the polygons to fill, this +2 on the outer edges
violates the winding rules that normally ensure the interior polygons
(that use +/-2 instead of +/-1) are always filled.
It appears a similar bug fix was added here:
https://skia-review.googlesource.com/c/skia/+/141952/
but then didn't survive a heavy refactor later:
https://skia-review.googlesource.com/c/skia/+/215094
To the best of my knowledge, this is achieving the same result as the
original fix but is updated to preserve winding scale for interior
polygons with overlap regions (the code checks for these, but they
seem pretty rare to me).
Bug: 1197461
Change-Id: I0d32820af8cfec92c46114aeaa58b6e340abdfca
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/397140
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Modifies helpers on GrGLSLGeometryProcessor that insert, set, and make
keys for view/local matrix uniforms to not omit the uniform when
the matrix is identity or use a float4 when it is scale/trans. Always
uses a 3x3.
Bug: skia:11844
Change-Id: I0f25b60b46b8932d7e2cac4a50159d22b9cd84d2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/395656
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Change-Id: Ie36ea4d5186f6cca341efc6300b813ec8255bdbb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/388457
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
For now, just bolt this onto the existing runtime effects. The next step
is to add dedicated modes to the compiler for shader vs. color filter.
Once we get there, we will be much more strict about main signature in
each mode (and start adding other per-mode error checking).
Bug: skia:11813
Change-Id: I27e27600209e9844ae107364baea2fb949b47c3f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/395838
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
We are up to having seven distinct types of codegen, and will soon have
an 8th (DSL C++).
Change-Id: I6758328390c234ba1d5c30c118199dbc820af52a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/395817
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
No functionality changes, just making the naming consistent with our
other enums.
Change-Id: Ic9bc4a89f8373e4dc1060067a41468fb626e5fa1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/394160
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
This reverts commit 92b35673c5.
Reason for revert: breaking the android roll (see ag/14076257)
Original change's description:
> Lift atlas clip FP creation out of GrClip::apply
>
> Atlas clips always had a potential point of failure: If the SDC's
> opsTask ever got closed between GrClip::apply and
> GrOpsTask::addDrawOp, their mask would have gotten sent to the wrong
> opsTask. It didn't _look_ like this could happen with the current
> code, but it could have also been inadvertently changed quite easily.
>
> This CL adds a "pathsForClipAtlas" array for GrClip::apply to fill out
> instead of creating FPs. The SDC then generates the actual clip atlas
> FPs once it knows exactly which opsTask they will belong in.
>
> Bug: chromium:928984
> Change-Id: I507ab13b2b5e8c3c3c1916d97611297dbbd8a522
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/389926
> Commit-Queue: Chris Dalton <csmartdalton@google.com>
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
TBR=robertphillips@google.com,csmartdalton@google.com,michaelludwig@google.com,adlai@google.com
Change-Id: I9597d822a9f31b7070aee691ddf3a52f4f424a24
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:928984
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/392339
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Derek Sollenberger <djsollen@google.com>
Atlas clips always had a potential point of failure: If the SDC's
opsTask ever got closed between GrClip::apply and
GrOpsTask::addDrawOp, their mask would have gotten sent to the wrong
opsTask. It didn't _look_ like this could happen with the current
code, but it could have also been inadvertently changed quite easily.
This CL adds a "pathsForClipAtlas" array for GrClip::apply to fill out
instead of creating FPs. The SDC then generates the actual clip atlas
FPs once it knows exactly which opsTask they will belong in.
Bug: chromium:928984
Change-Id: I507ab13b2b5e8c3c3c1916d97611297dbbd8a522
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/389926
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Change-Id: I37202f26bd1d990f80528f490ccd7e99cbc2139f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/392056
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Bug: skia:11803
Change-Id: I925f14be282b96355721986de6049090b35adf3d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/391856
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
The `compositor_quads_xxxxxx` slides were attempting to create their
renderers at program startup time. These are now created in
onOnceBeforeDraw instead.
Change-Id: I5dd5844447bf87348cb88ee97aa4e03593eb07fe
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/389616
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Found during implementation of COLRv1 fuzzer for FreeType that translate
operation was still missing.
Added a test glyph containing two squares filled with a radial gradient
shifted by dx 128, dy -128 and dx -308, dy 307
combined using a PaintComposite.
Bug: skia:11790
Change-Id: I4cbfe34a111a450777dc2f8fa9d32a405f808a89
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/389116
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Sk3Perspective -> SkM44::Perspective
Sk3LookAt -> SkM44::LookAt
Also adds some SK_API tags to the SkV[2,3,4] structs. Also fixes
linkage issues around Sk3Perspective/LookAt by moving them into the
exported SkM44 (if we don't like them as SkM44 factories, will just need
to add SK_API tags to old Sk3Perspective/Lookat directly).
Change-Id: I3f125211b76899f216e63cc8d587776004516e36
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/388476
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Bug: skia:11760, skia:11787
Change-Id: Idfedb90576e0484bf32a9002081c0fcb888141eb
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/388216
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Only the largest sigma (320) would hit the downscale limit with the
old sigmas and image sizes. However, that sigma was far too large
to produce reference values in a reasonable amount of time.
Reduce the image sizes so that the downscale limit can be hit with a
smaller sigma.
Bug: skia:11735
Change-Id: Ia7f4385c6114f7071a14336ca39f81cf9ac68861
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/386058
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
into a new GrGLSLGeometryProcessor. Since NVPR is no more this
distinction (between GLSL- Primitive and Geometry -Processor)
probably isn't needed/useful.
Bug: skia:11760
Change-Id: I75621725bd2b0ef3dbac2ea6449bd571551babab
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/388036
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
With the removal of NVPR we no longer need this distinction.
Bug: skia:11760
Change-Id: I225a4feb764395fb72aca3ffc8b6d05396bf0b1e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/386890
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
