* Enable MipmappedTest
* Add didWriteToSurface calls to fix up MipmapInvalidation test
* Add flush & submit to fix DDLSkSurfaceFlush test
Change-Id: I9c3cad96b40491a54cab4edb8f56639d6cc16665
Bug: skia:10446
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405496
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reformat uses to de-yodaify and try to improve readabilty of
complicated conditionals.
Change-Id: Ifccb84836cbe4f5a01813795ceb287089984f8ae
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405685
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This CL only handles a subset of our intrinsics. In particular, it
avoids changing the behavior of `sqrt` as many of our tests use sqrt as
an optimization barrier.
The transcendental test inputs are intentionally kept very simple to
avoid putting numbers in the test outputs which could round differently
on various platforms and cause Housekeeper to complain.
Change-Id: I539f918294332310dcd6fe12fab163c0b6216f65
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405398
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Previously, the code neglected to resolve constant variables into
values. This meant that expressions like `lessThan(zero, one)` could not
be compile-time evaluated even when `zero` and `one` have known values.
Change-Id: I2f5ce303e3dcc682be14e4d2485e24dd7c59212e
Bug: skia:10835
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405536
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Chromium has been updated to use makeAnalysisCanvas directly and there are
no more references to SkTextBlobDiffCanvas as a type in its code base.
Since the GlyphTrackingDevice extends SkNoPixelsDevice, any SkCanvas that
uses it is effectively a "no-draw" canvas. However, by returning a base
SkCanvas the text tracking now automatically happens in the context of
the base's AutoLayerForImageFilter handling it applies on every draw. This
means that drawing a text blob with an image filter that modifies the
transform state will now be analyzed in that context automatically
(simplifying code in chrome after this lands).
Another behavioral change is that all non-text draws will still go through
the base SkCanvas' virtuals and invoke the device function. Since it's an
SkNoPixelsDevice, it'll still be a no-op, it just happens a little later.
This won't really impact performance because oop-r already inspects their
operations and only plays back text and transform related ones to the
analysis canvas, so we shouldn't really see non-text draws being invoked
anyways.
Bug: chromium:1187246
Change-Id: I83f86571300751f385b3065dfe889f218fa1edc6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405196
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
This includes several new array variants of existing APIs, DSLBlock now
supporting SymbolTables, and a couple of other minor changes needed by
the upcoming DSLParser.
Change-Id: I71feb268feb27cf7ff453cc59046091779bffe06
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404779
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
If every argument passed to lessThan/greaterThan/lessThanEqual/
greaterThanEqual/equal/notEqual() is a compile-time constant, we now
detect this and optimize away the function call entirely.
Change-Id: I3415d21be6ef51b38b682a792bd118fad51957f5
Bug: skia:10835
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
If every argument passed to any() or all() is a compile-time constant,
we now detect this and optimize away the function call entirely.
Future CLs will perform a similar optimization on other intrinsic calls
which can be detected and eliminated at compile time, like lessThan().
Change-Id: Ie55aff538b1ccaf2b3bcf9a69573a85f081b7ade
Bug: skia:10835
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404417
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@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>
The SkM44::RectToRect function matches the semantics of
SkMatrix::RectToRect(kFill_ScaleToFit). No other ScaleToFit variants are
ported over to SkM44.
skottie uses some instances of kCenter_ScaleToFit so that functionality
may need to be added in the future (in SkM44 or in skottie). There are
no current usages of the kStart and kEnd_ScaleToFit semantics.
The SkM44::mapRect() function is implemented to correspond to the
SkMatrix::mapRect() that returns the mapped rect (instead of modifying a
pointer) and always has ApplyPerspectiveClip::kYes. This was chosen to
keep its behavior simple and because perspective clipping is almost
always the right thing to do. In the new implementation there is no
longer a performance cliff to worry about (see below). For the timebeing
mapRect is hidden behind SkMatrixPriv::MapRect().
Performance:
I added benchmarks for mapRect() on SkM44 and SkMatrix that use the same
matrices to get a fair comparison on their different specializations.
SkMatrix has a very efficient mapRect when it's scale+translate or
simpler, then another impl. for affine matrices, and then falls back to
SkPath clipping when there's perspective. On the other hand, SkM44 only
has 2 modes: affine and perspective.
On my desktop, with a Ryzen 9 3900X, here are the times for 100,000 calls
to mapRect for different types of matrices:
SkMatrix SkM44
scale+translate 0.35 ms 0.42 ms
rotate 1.70 ms 0.42 ms
perspective 63.90 ms 0.66 ms
clipped-perspective 138.0 ms 0.96 ms
To summarize, the SkM44::mapRect is almost as fast as the s+t specialization
in SkMatrix, but for all non-perspective matrices. For perspective matrices
it's only 2x slower than that specialization when no vertices are clipped,
and still almost 2x faster than the affine specialization when vertices are
clipped (and 100x faster than falling back to SkPath).
Given that, there's the open question of whether or not keeping an affine
specialization is worth it for SkM44's code size.
Bug: skia:11720
Change-Id: I6771956729ed64f3b287a9de503513375c9f42a0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402957
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Auto-Submit: Michael Ludwig <michaelludwig@google.com>
A constructor like `float3(five)` is not a compile-time constant, so we
miss optimization opportunities like folding. Constant variables inside
splat constructors are now replaced when optimization is on, so this
would optimize down to `float3(5.0)` and be eligible for folding.
Change-Id: I4bf6f52a48ef733e6b24791d02687081194ef488
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404676
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
A constructor like `float2(one, two)` is not a compile-time constant, so
we miss optimization opportunities like folding. Constant variables
inside compound constructors are now replaced when optimization is on,
so this would optimize down to `float2(1.0, 2.0)` and be eligible for
folding.
Change-Id: I80dd421f61d4eed21278805e2dc26d198a678e52
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404657
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
The Serialization_Typeface and FontMgr_AliasNames tests sometimes fail
on macOS 10.13 and 10.15.7 bots. This is likely fixed on macOS 11,
however in the interest of investigation there should be some attempt at
discovering if the retrieved fonts are actually different and which ones
were retrieved. Improve the reports with additional information about
the typefaces in question.
Change-Id: I0e4354eacf91be1ae98838569e4da9f964dc2ac8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404338
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
This breaks up the giant IRGenerator::convertFunction method into more-
manageable chunks, moves the functionality into FunctionDeclaration,
and funnels the DSL through it so it receives the same error checking.
Change-Id: Icf2ac650ab3d5276d8c0134062a4e7e220f9bf32
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402778
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
This will be used by the upcoming DSLParser, which needs to be able to
put DSLExpression and DSLVar into containers such as std::vector and
std::optional.
Change-Id: I8d367cfd0b3a852a368c69a5b3be6c0eaa41d74a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404156
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@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>
Change-Id: I721825d1a38e9f6846b94f84d14cb8c85b7a7519
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/403601
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@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 string had several characters which resulted in zero
glyphs. Having zero glyphs bypassed the buffer sizing code,
and continued to process the glyph run list assuming it had
7 runs because the buffer sizing code also clears the run list.
This caused the code to process runs from a previous SkTextBlob,
which was already deleted.
If the there are no glyphs, call the buffer sizing code to
set up all the invariants. Exit if there are no runs produced.
Bug: oss-fuzz:33915
Change-Id: I9f3f38a58112c44ddd65265c68d982b3b0dcd79c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/403439
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Change-Id: I06631e7f0db518f4de19a39bf1ed368afbd5d409
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/403076
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@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>
Previously, "x = 1.0" (as opposed to 1.0f) would fail with an ambiguous
operator resolution.
Change-Id: I9bcb4115d209a2aadb3fc4c237b61c345b25ca00
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/400619
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
This is a reland of 7b253d34eehttp://review.skia.org/402781 must land first, to resolve the assertions
we were getting on the Android bots.
Original change's description:
> Optimize away swizzles of constant variables.
>
> Change-Id: I49807f18ea54e85c2b8f1419278c54aa2d6f8fac
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402581
> Commit-Queue: John Stiles <johnstiles@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
> Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Change-Id: Ib4f494b16a89ff744d4384db95a8a86d9653c190
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402644
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This is a reland of 830c69ca66
Original change's description:
> Implement operator== and != for Metal structs and arrays.
>
> GLSL/SkSL assumes that == and != on struct/array types should work.
> We need to emit equality and inequality operators whenever we find code
> that compares a struct or array.
>
> Structs and arrays can be arbitrarily nested, and either type can
> contain a matrix. All of these things need custom equality operators in
> Metal. Therefore, we need to recursively generate comparison operators
> when any of these types are encountered.
>
> For arrays we get lucky, and we can cover all possible array types and
> sizes with a single templated operator== method. Structs and matrices
> have no such luck, and are generated separately on a per-type basis.
>
> For each of these types, operator== is implemented as an equality check
> on each field, and operator!= is implemented in terms of operator==.
> Equality and inequality are always emitted together. (Previously, matrix
> equality and inequality were emitted and implemented independently, but
> this is no longer the case.)
>
> Change-Id: I69ee01c0a390d7db6bcb2253ed6336ab20cc4d1d
> Bug: skia:11908, skia:11924
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402016
> Auto-Submit: John Stiles <johnstiles@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:11908, skia:11924, skia:11929
Change-Id: I6336b6125e9774c1ca73e3d497e3466f11f6f25f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402559
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Bug: chromium:1202417
Change-Id: Ie6a31b2a9999280c9771a3c8d8fa92d77c01cf03
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402259
Auto-Submit: Brian Salomon <bsalomon@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@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>
At present, this is a missed optimization opportunity. These will be
optimized in a followup CL.
Change-Id: I8882058900cdc12c8ab0df03e36ebfb9d8022f01
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402580
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This reverts commit 830c69ca66.
Reason for revert: Pixel5 issues on tree
Original change's description:
> Implement operator== and != for Metal structs and arrays.
>
> GLSL/SkSL assumes that == and != on struct/array types should work.
> We need to emit equality and inequality operators whenever we find code
> that compares a struct or array.
>
> Structs and arrays can be arbitrarily nested, and either type can
> contain a matrix. All of these things need custom equality operators in
> Metal. Therefore, we need to recursively generate comparison operators
> when any of these types are encountered.
>
> For arrays we get lucky, and we can cover all possible array types and
> sizes with a single templated operator== method. Structs and matrices
> have no such luck, and are generated separately on a per-type basis.
>
> For each of these types, operator== is implemented as an equality check
> on each field, and operator!= is implemented in terms of operator==.
> Equality and inequality are always emitted together. (Previously, matrix
> equality and inequality were emitted and implemented independently, but
> this is no longer the case.)
>
> Change-Id: I69ee01c0a390d7db6bcb2253ed6336ab20cc4d1d
> Bug: skia:11908, skia:11924
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402016
> 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: I06c47923649ea9fb675bab6baab121eb504d5ab8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:11908
Bug: skia:11924
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402558
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
GLSL/SkSL assumes that == and != on struct/array types should work.
We need to emit equality and inequality operators whenever we find code
that compares a struct or array.
Structs and arrays can be arbitrarily nested, and either type can
contain a matrix. All of these things need custom equality operators in
Metal. Therefore, we need to recursively generate comparison operators
when any of these types are encountered.
For arrays we get lucky, and we can cover all possible array types and
sizes with a single templated operator== method. Structs and matrices
have no such luck, and are generated separately on a per-type basis.
For each of these types, operator== is implemented as an equality check
on each field, and operator!= is implemented in terms of operator==.
Equality and inequality are always emitted together. (Previously, matrix
equality and inequality were emitted and implemented independently, but
this is no longer the case.)
Change-Id: I69ee01c0a390d7db6bcb2253ed6336ab20cc4d1d
Bug: skia:11908, skia:11924
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402016
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@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>
There aren't many cases where array-of-struct types are useful in
ES2, but it looks like function parameters are one such case:
http://screen/7Fnc7GhewAkUK3j
Change-Id: I23410a3824a3c202c12147d6939586cc0e55a9ce
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402397
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 CL adds a RuntimeEffect option flag which skips over the various
`strictES2Mode` checks sprinkled throughout IR generation.
Runtime Effects still won't allow a lot of ES3 things (the Pipeline
stage will reject unsupported statement types, SkVM doesn't support most
non-ES2 constructs, etc). However, this change will give us the ability
to test many more features involving arrays and structs that previously
were off-limits due to ES2 restrictions, and will shore up some
legitimate gaps in our testing. This is a useful starting point to allow
for improved test coverage.
Change-Id: I4a5bc43914e65fc7e59f1cecb76a0ec5a7f05f2f
Bug: skia:11209
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402157
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>
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>
and remove SkRuntimeEffectInvalidColorFilters.
Change-Id: I80753e635fb0b2e93637a8b2a7f2add66020e4c1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402196
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This is completely unused - GrMatrixEffect is the only thing that deals
with matrix transforms on child sampling. Removing this makes everything
simpler to reason about.
Change-Id: I555a3fd937c064f2480b149a6d4d8e36f7ee69bc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402176
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
All clients have been moved to the stage-specific factories. The old
flexible factories are still used internally (for now), but this
prevents any new usage from creeping in accidentally.
Bug: skia:11813
Change-Id: I6c34dfd19b396541f9a0e2f9eab8a51591ed8b70
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/402156
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Global variables which can be calculated in C++ code are now written as
constant values in the DSL, instead of performing the same logic
redundantly in the shader.
In some cases this can be fairly significant, e.g. RectBlurEffect has
a global with the expression
abs(rect.x) > 16000 || abs(rect.y) > 16000 ||
abs(rect.z) > 16000 || abs(rect.w) > 16000
Change-Id: I84221f60a4986b3225afcf91ef95cdcfc941b4b7
Bug: skia:11854
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401437
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This undoes the change from http://review.skia.org/400541 and reworks
sk_Caps to use macros, exactly like the existing CPPCodeGenerator.
This compromise is necessary for when-expressions. Specifically, when-
expressions must be valid when parsed *either* as SkSL or as C++. We
want to support when-expressions that reference sk_Caps, like:
layout(when=!sk_Caps.floatIs32Bits)
The macro approach allows this when-expression to work.
Change-Id: I346762fb14c0b2f0c10015497f902f037e3461a9
Bug: skia:11854
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401157
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
When emitting a built-in function call, we need to honor the `fCPPMode`
state. Previously we were rewriting the call into a DSL call even in C++
mode.
We also now spell out Fract's complete namespace, to avoid a name
collision with MacTypes.h:
https://opensource.apple.com/source/CarbonHeaders/CarbonHeaders-18.1/MacTypes.h.auto.html
typedef SInt32 Fract;
Change-Id: I752b7816a64a9b2b2c79d92fe46cd774e1bab96a
Bug: skia:11854
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401678
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This lets the user query if a task is skippable, makes
the naming clearer, and only calls the virtual once.
Bug: skia:10877
Change-Id: Ia8a7e0e3014d447bd8b4e914edf4f705a2ea107b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401856
Commit-Queue: Adlai Holler <adlai@google.com>
Auto-Submit: Adlai Holler <adlai@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This is a reland of 22dcb5fd7e
Original change's description:
> Add coords parameter to all .sksl test files used as runtime effects
>
> Convert to use the newer MakeForShader factory, which requires this.
>
> Change-Id: Ifaf6054054027c78f3f3fe15596e435e0f79b877
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/399336
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: John Stiles <johnstiles@google.com>
Bug: skia:11919
Change-Id: I5f745c54b2bc3712f2281db6e067345903e81931
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401836
Reviewed-by: Brian Osman <brianosman@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.
Reland changes the logic in GrSkSLFP slightly, to avoid turning all
samples into pass-through when a child is sampled with both pass-through
and explicit coordinates.
Bug: skia:11869
Change-Id: Iec18f059b4e78df0d2f53449aa0c2945c58a58f7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401677
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
This reverts commit cc3d2d25c5.
Reason for revert: Subtle bug snuck past testing.
Original change's description:
> Runtime effects: Detect passthrough sample calls automatically
>
> 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>
Bug: skia:11869
Change-Id: Icfc756cde745d450966eaa49f5067a73232635b1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401158
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit 22dcb5fd7e.
Reason for revert: Lot's of red Android and Win bots.
Original change's description:
> Add coords parameter to all .sksl test files used as runtime effects
>
> Convert to use the newer MakeForShader factory, which requires this.
>
> Change-Id: Ifaf6054054027c78f3f3fe15596e435e0f79b877
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/399336
> Commit-Queue: Brian Osman <brianosman@google.com>
> Reviewed-by: John Stiles <johnstiles@google.com>
TBR=brianosman@google.com,ethannicholas@google.com,johnstiles@google.com
Change-Id: I0fa844c6cf985d16e72c7f26aa217752612dcfc1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401077
Reviewed-by: Joe Gregorio <jcgregorio@google.com>
Commit-Queue: Joe Gregorio <jcgregorio@google.com>
Convert to use the newer MakeForShader factory, which requires this.
Change-Id: Ifaf6054054027c78f3f3fe15596e435e0f79b877
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/399336
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
The comma-warning issue has since been fixed, and we don't need to
use `(void) var;` when we have C++17's [[maybe_unused]] attribute.
Change-Id: I2078354f06801b024638e9c7d9ac699df20a8c48
Bug: skia:11854
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401116
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
