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>
This is needed by the upcoming DSLParser.
Change-Id: I54a0714e55feeb78894df766b14c795970f2c2d4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/411308
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
This extracts the logic for SkRuntimeEffect's one-at-a-time handling of
colors, and also makes it more capable. We can now execute color filters
that invoke children with literals, or with the results of other
children (eg, compose color filter).
Change-Id: I53c6db0316a7162c32f2a7b86b35c947cccb42ea
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/408117
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Previously we would completely disable hardware tessellation for a path
if there was any chance of a curve requiring more segments than
supported by the hardware. This CL updates the tessellators to simply
chop paths until they fit in patches, allowing us to finally draw any
path using hardware tessellation.
Bug: skia:10419
Change-Id: I5c9f78cda3e30b8810aff3cb908235965706f2d8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/410977
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
I think this finishes all public subclasses, so we can proceed next with
moving the virtuals themselves to a private subclass.
Change-Id: I490f3cf6497a6bdcafc1ce756cfdeb32eab18585
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/411239
Reviewed-by: Tyler Denniston <tdenniston@google.com>
Commit-Queue: Mike Reed <reed@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>
- Remove ctypes that were entirely unused
- Remove explicit selection of default ctypes
- After that, only two ctype tokens are needed (SkPMColor4f and SkV4)
... remove all of the others from the parser
Change-Id: I2322aab73a19127b3b26850aefdad6140ea0f7e7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/410057
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Will be used to figure out an appropriate SkColorType for
YUVA images made of texture planes.
Bug: chromium:1113801
Change-Id: I5e1733292a84e082068c9c3557f629856b7aea84
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/410097
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This was only used in the context of sk_SampleMask, which was removed
recently.
Change-Id: Id70d7af8b3a100ff157c2984bad4131f1b92f317
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/410056
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Change-Id: I6019418526def09c6c9f4b22567a2c76542d043c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/409876
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
The DSL would not previously function within the compiler, because it
expected to be in charge of everything itself. The compiler and DSL also
disagreed about how to handle some things, such as the DSL not
respecting the compiler's override flags.
This CL moves responsibility for much of the setup process into
DSL::Start(), which the compiler now invokes. DSL::Start() now also
takes a ProgramSettings instead of DSL-specific flags, and the
externalFunctions vector has been moved into ProgramSettings.
Change-Id: I283ed8366e25d67f02c43833743c5f8afdedaefc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/408136
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Want to also use this to use this for texture formats so remove
"ColorType" from name.
Also class rather than struct.
Bug: chromium:1113801
Change-Id: Ieb08a3d81c465b92b956d9bc04b39c5783715ea8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/409476
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Already exposed (on TextBlob), so this makes it available for clients
that may use drawGlyphs directly. (including canvaskit/flutter)
Change-Id: I8b4bd51e13827dc3970d5a6d06f0e0d3031af13c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/408638
Reviewed-by: Julia Lavrova <jlavrova@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Change-Id: Ie1eac40fe678529410f3ae4ab0cc7460dedfa4c2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/408296
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Both SkColorData.h and SkNx_sse.h are in include/private, but not
(currently) included by any public headers. Adding them to a public
header reveals warnings about implicit conversion changing signedness
(-Wsign-conversion), enforced in our public headers warnings check.
Bug: skia:11995
Change-Id: Iee44b24a6df031431113e2d25e42f0a8dd55a5c0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/408056
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Herb Derby <herb@google.com>
This is a reland of 0a0f4f5c35
This change makes SkCanvas::quickReject always reject empty draw bounds,
whereas previously scale+translate CTMs allowed bounds with w or h == 0
but otherwise contained in the clip to be drawn. This uncovered some
bugs in Skia where bounds shouldn't be empty, and in Flutter where
bounds were legit empty but not expected by the test.
No code changes needed. The issues that required its revert have been
fixed with:
1. https://github.com/flutter/engine/pull/26053 so that platforms that
use an empty typeface, leading to empty draws are just skipped.
2. https://skia-review.googlesource.com/c/skia/+/406140 so that path
effects update bounds so that Android's 1D dash path effect applied to
a horizontal line is properly not rejected.
Based on the period of time where the original CL was landed, some perf
data was collected.
- There were no significant changes in most SKPs or SVGs, except for a
Flutter page flip skp, which saw a 10% net improvement (perhaps the
flip is drawn with perspective?)
- A 10-20% regression in the motionmark paths skp, but dominated by the MSVC
compiler, so I'm not too concerned about that.
- Perspective microbenchmarks for drawing rectangles are 1.5-2x faster.
- quickReject microbenchmarks are about 2x slower.
The last two microbenchmark results aren't surprising since perspective
was the largest improvement in perf for SkM44::MapRect vs.
SkMatrix::mapRect, and the scale+translate specializations in Skmatrix
were maybe 50% faster than SkM44's. That would account for some of the
slow downs, and the rest could be explained by moving away from the
SIMD rect intersection and nan test.
Since these microreductions don't seem to bleed into more complex
benchmarks, I'm inclined to keep the code simple and not bring back the
custom intrinsics.
Original change's description:
> Simplify quickReject implementation in SkCanvas
>
> - SkCanvas no longer keeps fIsScaleTranslate bool that has to stay in
> sync with the type of the matrix.
> - No more fast or slow path for quickReject, the Sk4f code has been
> completely removed.
> - Uses SkM44::mapRect instead of SkMatrix::mapRect. This is slightly
> slower for S+T, but much faster for other transforms. I'm hopeful we
> won't notice the regression in the grand scheme for S+T, since the
> code is a lot simpler now.
> - The final isFinite() and intersects() check for quickReject uses
> SkRect's functions instead of hand-written SSE/NEON. If we think this
> is optimization is necessary, I'm hoping we can rewrite it in terms
> of skvx instead of specific instructions.
> - Consolidated how the quick-reject bounds outsetting into
> computeDeviceClipBounds, and added an option to skip outsetting for
> the one call site that doesn't want it.
>
> Bug: skia:10987
> Change-Id: I3cf2a73636cdeed06d12cab4548cfb94d1eb074a
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405198
> Commit-Queue: Mike Reed <reed@google.com>
> Auto-Submit: Michael Ludwig <michaelludwig@google.com>
> Reviewed-by: Mike Reed <reed@google.com>
Bug: skia:10987
Change-Id: Id0d4b4ecebf0b83ae30f7e1a263961ab25de28dd
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/407358
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: 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>
This reverts commit 71430593f0.
Reason for revert: Clang-tidy bot unhappy. (Not sure how this slipped by).
Original change's description:
> Added DSL flags
>
> This adds some basic flags to the DSL initialization which allows us to
> toggle things like optimization and validation.
>
> Change-Id: I35b10526af1678c88901eaacd5a2c4a9f5cd21a7
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/406896
> Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
> Reviewed-by: John Stiles <johnstiles@google.com>
TBR=brianosman@google.com,ethannicholas@google.com,johnstiles@google.com
Change-Id: I7512b8bcc6e94707949904eec42c396faa7fdaf8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/407176
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This adds some basic flags to the DSL initialization which allows us to
toggle things like optimization and validation.
Change-Id: I35b10526af1678c88901eaacd5a2c4a9f5cd21a7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/406896
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
- expand SkParsePath to support relative path encoding
- introduce a new SkSVGCanvas flag for clients to opt into relative
encoding
Bug: skia:11981
Change-Id: I2d6c63254df23311f1a86dee9481bde9531c3b61
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/406876
Reviewed-by: Tyler Denniston <tdenniston@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Florin Malita <fmalita@google.com>
Makes computeFastBounds not part of the public API, it's only accessible
to subclasses of SkPathEffect, GrStyle, and SkPaint. Subclasses can
invoke it other path effects using SkPathEffectPriv::ComputeFastBounds.
Changes the internal function to
bool computeFastBounds(SkRect* bounds) const;
Subclasses of SkPathEffect must implement this, and can choose to return
false when fast bounds aren't computable.
Provides implementations of computeFastBounds() for path effects
bundled with Skia.
Bug: skia:11974
Change-Id: I545ccf99b4e669d3af9df13acfac28573306fab8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/406140
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Mike Reed <reed@google.com>
This layout qualifier is not actually used anywhere.
Change-Id: I817c9affdd00e492c70f251eb52680644b7ff3f7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/406141
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
SkSpan is a convenient type to use on API boundaries - callers can have
their collection in a stack-allocated array, or any contiguous container
(std::vector, etc). Those will all implicitly convert to SkSpan, making
call-sites easy to read/write.
Before making it part of Skia's public API, this CL removes parts of the
API that aren't present in std::span -- when Skia moves to C++20, this
should allow us to use std::span instead, and remove SkSpan entirely.
The most disruptive change is the removal of `int count()`. That's
replaced by a new free function `SkCount` that works on any container,
and incorporates the overflow check from SkTo<int>.
Change-Id: I86cdfad1700f341da3b81a965b396ca9d8b79df9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405816
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Add an assert in SkTHashTable::uncheckedSet that each added key is equal
to itself. This is an implied precondition which is easy to get wrong if
the key contains floating point values which may become NaN.
Motivated by https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=30314
which would have been much easier to track down with this assert, since
the issue would have been discovered at insertion instead of much later
on removal.
Change-Id: I4eabb6892d2bff1e7bc33c04fd6b297b189a3b02
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405695
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Note: Shouldn't add or change the Skia API, only accepts an optional z value to preScale()
Change-Id: Ic73c723ebc2b75acca1fce5395953434ef1582e6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/404376
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Jorge Betancourt <jmbetancourt@google.com>
This reverts commit 0a0f4f5c35.
Reason for revert: possible cause of flutter roll failure
Original change's description:
> Simplify quickReject implementation in SkCanvas
>
> - SkCanvas no longer keeps fIsScaleTranslate bool that has to stay in
> sync with the type of the matrix.
> - No more fast or slow path for quickReject, the Sk4f code has been
> completely removed.
> - Uses SkM44::mapRect instead of SkMatrix::mapRect. This is slightly
> slower for S+T, but much faster for other transforms. I'm hopeful we
> won't notice the regression in the grand scheme for S+T, since the
> code is a lot simpler now.
> - The final isFinite() and intersects() check for quickReject uses
> SkRect's functions instead of hand-written SSE/NEON. If we think this
> is optimization is necessary, I'm hoping we can rewrite it in terms
> of skvx instead of specific instructions.
> - Consolidated how the quick-reject bounds outsetting into
> computeDeviceClipBounds, and added an option to skip outsetting for
> the one call site that doesn't want it.
>
> Bug: skia:10987
> Change-Id: I3cf2a73636cdeed06d12cab4548cfb94d1eb074a
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405198
> Commit-Queue: Mike Reed <reed@google.com>
> Auto-Submit: Michael Ludwig <michaelludwig@google.com>
> Reviewed-by: Mike Reed <reed@google.com>
TBR=mtklein@google.com,reed@google.com,michaelludwig@google.com
Change-Id: I1a373740ee167827b9a6a2eee9afb7f814641fb0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:10987
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405616
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
- SkCanvas no longer keeps fIsScaleTranslate bool that has to stay in
sync with the type of the matrix.
- No more fast or slow path for quickReject, the Sk4f code has been
completely removed.
- Uses SkM44::mapRect instead of SkMatrix::mapRect. This is slightly
slower for S+T, but much faster for other transforms. I'm hopeful we
won't notice the regression in the grand scheme for S+T, since the
code is a lot simpler now.
- The final isFinite() and intersects() check for quickReject uses
SkRect's functions instead of hand-written SSE/NEON. If we think this
is optimization is necessary, I'm hoping we can rewrite it in terms
of skvx instead of specific instructions.
- Consolidated how the quick-reject bounds outsetting into
computeDeviceClipBounds, and added an option to skip outsetting for
the one call site that doesn't want it.
Bug: skia:10987
Change-Id: I3cf2a73636cdeed06d12cab4548cfb94d1eb074a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/405198
Commit-Queue: Mike Reed <reed@google.com>
Auto-Submit: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Mike Reed <reed@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>
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>
This removes the templated versions of these operators. This should help
the case where clients would get compiler errors in their code with
errors claiming failed matches to these ganesh operators. The errors were
correct, but would be confusing for clients to see. Now with this change
the various operators are defined for specific types so a client shouldn't
get errors for their own enums anymore.
Bug: chromium:1204688
Change-Id: Ie3450834da7734a161af303ca6c8f458dd173513
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/403596
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@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>
Being able to Construct() arbitrary types is necessary for the upcoming
DSLParser.
Change-Id: I2d439b4a1db7a460043efa5f0e9207b6073e9f1f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/403696
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>
Adds counters for the number of render passes, number of MSAA render
passes, and each op that either does or would trigger MSAA. Adds a
bot that collects stats on the html (not svg) skps.
Bug: skia:11396
Change-Id: Ic48263d6310670d8f0d09ec4c4bf6a2b83fc7d02
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/401636
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Kevin Lubick <kjlubick@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>
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>
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>
