This is a reland of e58831cd95
Original change's description:
> Add format-specifier warnings to SkDebugf.
>
> This CL fixes up many existing format-specifier violations in Skia.
> Note that GCC has a warning for formatting nothing, so existing calls to
> `SkDebugf("")` have been removed, or replaced with `SkDebugf("%s", "")`.
> These were apparently meant to be used as a place to set a breakpoint.
>
> Some of our clients also use SkDebug with bad format specifiers, so this
> check is currently only enabled when SKIA_IMPLEMENTATION is true.
>
> Change-Id: I8177a1298a624c6936adc24e0d8f481362a356d0
> Bug: skia:12143
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/420902
> Auto-Submit: John Stiles <johnstiles@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:12143
Change-Id: Id3c0c21436ebd13899908d5ed5d44c42a0e23921
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/421918
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit e58831cd95.
Reason for revert: looks like breaking a few build bots
Original change's description:
> Add format-specifier warnings to SkDebugf.
>
> This CL fixes up many existing format-specifier violations in Skia.
> Note that GCC has a warning for formatting nothing, so existing calls to
> `SkDebugf("")` have been removed, or replaced with `SkDebugf("%s", "")`.
> These were apparently meant to be used as a place to set a breakpoint.
>
> Some of our clients also use SkDebug with bad format specifiers, so this
> check is currently only enabled when SKIA_IMPLEMENTATION is true.
>
> Change-Id: I8177a1298a624c6936adc24e0d8f481362a356d0
> Bug: skia:12143
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/420902
> Auto-Submit: John Stiles <johnstiles@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
TBR=brianosman@google.com,ethannicholas@google.com,johnstiles@google.com
Change-Id: I07848c1bf8992925c9498e916744d0840355a077
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:12143
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/421917
Reviewed-by: Tyler Denniston <tdenniston@google.com>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
This CL fixes up many existing format-specifier violations in Skia.
Note that GCC has a warning for formatting nothing, so existing calls to
`SkDebugf("")` have been removed, or replaced with `SkDebugf("%s", "")`.
These were apparently meant to be used as a place to set a breakpoint.
Some of our clients also use SkDebug with bad format specifiers, so this
check is currently only enabled when SKIA_IMPLEMENTATION is true.
Change-Id: I8177a1298a624c6936adc24e0d8f481362a356d0
Bug: skia:12143
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/420902
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This CL preserves the "StringFragment" name as an alias for
string_view to reduce the impact. The StringFragment alias
will be removed in a followup CL.
Change-Id: I89209bc626b0be0d0190823b6217f4c83cafe1bc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/416736
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Previously, when converting a program, the pipeline stage could assume
that an input to main() of type half4/float4 was always the input color.
This was a good assumption since the only possible inputs were
coordinates, or the input color.
This CL now recognizes that when a second float4 is passed to the main()
function, it should be a SK_DEST_COLOR_BUILTIN. This will let blend
functions pass in two colors.
ProgramToSkVM now takes a dest-color argument as well, but existing call
sites won't reference it (since they aren't for blend functions). I've
just passed the input-color a second time, since the value will never
actually be accessed.
Change-Id: I4214586bda605c6d287aa25b1b099e6ef5ba15a4
Bug: skia:12080
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/417261
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@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>
It took a few "independent" changes in order to get the linked fuzzer
bugs to pass without failing. Leaving any out triggered an issue :/
1. I changed nearly_flat to be <= epsilon, since if it's == epsilon and
we split the edge, then the new coordinates would have
difference < epsilon.
2. I updated double_to_clamped_scalar to also snap very small values to
0 (right now 16 * float epsilon).
3. double_to_clamped_scalar is now used to clean up the computed
intersection of two edges, and is used to process all initial
vertices (in case the curve evaluation generates lots of denormals
etc.)
4. I updated the use of nearly_flat in checkForIntersection to report
no intersection if both lines are nearly_flat. The comments suggest
nearly_flat means you can't split along that line since the new
coord is incalculable. So if both lines are flat, it's a really
tough numerical scenario and I just punt.
Then I made a few other changes for the fuzzer and debugging:
1. Added more logging messages and updated the code so that it compiles
correctly if TRIANGULATOR_LOGGING is defined.
2. I was also getting asserts in the fuzzer because the vertex
allocator expects the vertex buffer to be detached by the path
renderer before its destroyed, so I just have the fuzzer detach and
discard it. Running locally, the fuzzer test cases from the two
linked bugs pass successfully without oom'ing or timing out.
Bug: oss-fuzz:33672, oss-fuzz:33620
Change-Id: I7687b920db0a9e200b3fa79b323974b7812e52ff
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404120
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@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>
All internal usage has migrated to MakeFor..., this removes the old
program kind, and updates some tests.
Bug: skia:11813
Change-Id: I56733b071270e1ae3fab5d851e23acf6c02e3361
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402536
Commit-Queue: Brian Osman <brianosman@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>
New entry point that does stricter checking on SkSL validity.
Bug: skia:11813
Change-Id: Icc8501c108af278e2fe1029859a552ea6ab6eb08
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401056
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Brian Osman <brianosman@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>
Previously, the act of painting a Runtime Effect was causing its helper
functions to get inlined, even if inlining was disabled during the
initial SkSL generation. This meant that the "NoInline" path was not
actually very effective.
Change-Id: If8e3933be61df4a49d2e11d916d7fff22876315e
Bug: skia:11362
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/388099
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This was landed but not turned on. D'oh!
Bug: skia:10286
Change-Id: I65682370046c87c854d806253db32795ef3a9d14
Cq-Include-Trybots: luci.skia.skia.primary:Fuzz-Debian10-Clang
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/375736
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Adlai Holler <adlai@google.com>
This helps us find any issues with the promise image sharing.
Bug: skia:10286
Change-Id: I393655c2de76f896d9f376765894f84c015b2760
Cq-Include-Trybots: luci.skia.skia.primary:Fuzz-Debian10-Clang
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/374317
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Adlai Holler <adlai@google.com>
Bug: skia:11295
Change-Id: Iec11f3f4d26eb5b1c07707b3cedd09096bad80d0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/371478
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Change-Id: I7be9a95bc190760245966c36ed088afd68108a5f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/371316
Auto-Submit: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This change will allow these types to be forward-declared; C++ doesn't
allow forward declaration of types declared inside a struct. Moving
these types out of Programs resulted in a large diff.
The Settings::Value helper class has been moved inside of the
IRGenerator. In practice, it was actually just an implementation detail
of how IRGenerator looks up caps-values by name. It seems very unlikely
that this will be necessary elsewhere going forward.
Change-Id: I6119417fae608f1c492a27de746d2b550ef8ca20
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/370836
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Small diffs in a GM -- due to the dual nature of kMedium (cpu and gpu)
Another reason to stop using it, and switch to the more-explicit
sampling.
Bug: skia:7650
Change-Id: Ie7575071b19778626da7f94804abaaa11861a050
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/370259
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Uses the pipeline-stage callback mechanism. It mangles the type name
(with a test to verify that this works), and then calls defineStruct
with the entire SkSL struct definition string.
Bug: skia:10939
Change-Id: If14cf1b11faaa80ad8d4086cdacf68532bac43fc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/368809
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Structs, enums, and global variables are all going to require name
mangling. Move that to a separate virtual on the callback. More
importantly, the generator is going to need to do type-name substitution
inside the function declaration string, so the contract has shifted:
The generator constructs the entire function declaration line (using the
mangled name it gets from the new callback), then it calls
defineFunction with two strings, and a flag indicating if this is main
or not.
Bug: skia:10939, skia:11295, skia:11296
Change-Id: I535eee9bfbb2337013b539908fe3d658ec3b2dbd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/368397
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
There is now PipelineStage::ConvertProgram, which takes a collection of
callbacks, and processes an entire program. For program objects that may
need name mangling, the callbacks return the new name, which is recorded
and used for future references to that object (eg uniforms & functions).
The callbacks let the FP inject new elements programmatically:
- Declare uniforms and get handles
- Emit child functions
- Invoke child processors for calls to sample()
In a follow-up CL, we can add an skslc `.rte -> .sksl` mode, where the
callbacks just emit the description() of the relevant element. We can
also follow the same pattern to emit declarations of types (structs,
enums), and global variables.
Change-Id: I81df68a2f41bcb48f866d37af3b77ad43e880236
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/367058
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
This is now structured like the VM generator: Just a function that does
the conversion. Moved all relevant types and constants out of the
compiler, too. The key thing is that we don't need/want an error
handler, because it's too late to fail. We *must* catch all errors
during IR generation.
This is also another step along the path of directly emitting to the
fragment shader builder, rather than generating strings with
placeholders.
Bug: skia:11127
Change-Id: I18591270aa6e56dae1f040275a4b7d4a245007db
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/366956
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
This allows us to control the inline threshold of runtime effects in a
thread-safe way.
The new Make API now returns a struct, for readability; the old Make API
continues to return a tuple.
The old Make function is deprecated and subject to removal. You can
migrate to the new API by passing a default-constructed Options struct.
In this case there will be no difference in behavior.
Change-Id: Ic62d6f294f596d0a61095e35a87ccdbbe0b1cf93
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/363785
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Moves the (SkRect + flags) struct into SkImageFilter_Base with protected
access only. Base constructor and all src/effects/imagefilters Make
functions now take a "const SkRect*" instead. CropRect is still what's
stored and used by filter implementations during filterImage(), but it's
no longer publicly available.
The SkImageFilters factory implementations now can go straight to the
Make functions in src/effects/imagefilters instead of wrapping its
"const SkRect*" in an SkImageFilter::CropRect.
Bug: skia:9296, skia:11230
Change-Id: I2c62f42031910ec405623d4519c8a434cd2b3bdd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/361496
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
Auto-Submit: Michael Ludwig <michaelludwig@google.com>
Also cleanup some of the duplicate code in SkRecords
Bug: skia:7650
Change-Id: I4d3167a892c126c19a54002beab25c9a6c96fa5d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/357000
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Rough first pass at SkParagraph fuzzing. Lots of things not yet fuzzed.
--FontCollection cribbed from SkParagraphTest
--Current flow:
---Fuzz ParagraphStyle
---Add text and style some random small number of times.
---Text is either ASCII, unicode, or 'Zalgo'.
Although there are many todos, want to go ahead and submit this
~unchanged so the existing test cases that have found bugs are
not invalidated by a changing binary.
Change-Id: I38adca5fa79cfb20068fdf2fb431f90de55a2afc
Bug: skia:10894
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/336438
Commit-Queue: Weston Tracey <westont@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
This maps to usage better, and makes some code simpler to understand.
Note that there is still a PipelineStage *back-end*, which is specific
to the runtime-effect FP. A kRuntimeEffect_Kind program can be used to
generate a PipelineStage (for the GPU backend), or an skvm program (for
the CPU backend).
Change-Id: Id3f535db93a239726c595225aafe9467f0d19817
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/344969
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This ties the caps to the compiler instance, paving the way for
pre-optimizing the shared code. Most of the time, the compiler is
created and owned the GPU instance, so this is fine. For runtime
effects, we now use the shared (device-agnostic) compiler instance
for the first compile, even on GPU. It's configured with caps that
apply no workarounds. We pass the user's SkSL to the backend as
cleanly as possible, and then apply any workarounds once it's part
of the full program.
Bug: skia:10905
Bug: skia:10868
Change-Id: Ifcf8d7ebda5d43ad8e180f06700a261811da83de
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/331493
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Move the SVG rendering code to modules/svg, and componentize.
Also split into include/src/utils.
As external clients still reference the old header locations,
introduce temporary forwarding headers to facilitate the migration.
This reverts commit d6cf56fd34.
TBR=
Change-Id: Ibadd7c8dc0464ec0c27841530ade0c2098305d20
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/327344
Commit-Queue: Florin Malita <fmalita@google.com>
Reviewed-by: Florin Malita <fmalita@google.com>
Step one is to make it private -- only skottie needs it at the moment
Stpe two is to modify pathops to use builders, and then we can likely
remove it shrinkToFit entirely (since builder.snapshot() is already snug).
bug: skia:9000
Change-Id: I9126bcb6fc2094fbeede2acb1f211b0ab771feba
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/327341
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Reed <reed@google.com>
This reverts commit 6fc4106a9d.
Reason for revert: Blocking the Android roll
Original change's description:
> [svg] Relocate out of experimental
>
> Move the SVG rendering code to modules/svg, and componentize.
> Also split into include/src/utils.
>
> As external clients still reference the old header locations,
> introduce temporary forwarding headers to facilitate the migration.
>
> Change-Id: Ib289dbdcd80c16a01c47805e7242f2e08bebc165
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/326948
> Reviewed-by: Tyler Denniston <tdenniston@google.com>
> Commit-Queue: Florin Malita <fmalita@google.com>
TBR=fmalita@chromium.org,fmalita@google.com,tdenniston@google.com
Change-Id: I386cf77a15a9e1d392029804abaf937dae53f435
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/327342
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
