SkRuntimeEffect::MakeForXxxxx compiles its shaders before MakeTraced()
is invoked, with optimizations enabled. When MakeTraced() is called,
we recompile the shader with optimizations disabled; this allows us to
present the user with a shader that is as close to the original as
possible. (This obviously costs time, but debug trace generation isn't
focused on speed.)
Note that in some rare instances, disabling optimizations can cause
compilation to fail (e.g. optimization can simplify control flow and
eliminate "unreachable" paths). In those cases, we fall back to the
existing behavior of debugging an optimized shader.
Change-Id: Iba0f31bc42374c7048694fde5415b122177a9a68
Bug: skia:12666
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/489716
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
These convert a color between the working color space and a known,
useful space (linear TF, sRGB gamut).
Bug: skia:10479
Change-Id: I3308e691beeaca5120ed0c2e30cf08661caa3684
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/481416
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Color filters and blenders are currently not supported for tracing,
because we don't have access to the pixel coordinate, and so there is
nothing to compare the debug-trace coordinate with.
Change-Id: I7fe7fb4955b002432046ceef61c6f0a4c721a581
Bug: skia:12708
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/481278
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Added comments to explain the semantics (both what's expected when you
set the uniform, and what you see in the shader). The old name was
confusing, because it sounded like you got an sRGB color in the shader.
This is terse, but I think it's the cleanest syntax - and for embedding
clients, they can use C++ (etc.) API to require that color uniforms are
assigned from color types.
Bug: skia:10479
Change-Id: If00ea754060494aaa83001a5b357687953de8a5f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/480577
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
As a follow-up to https://skia-review.googlesource.com/c/skia/+/476219,
this sketches out how we can maybe use cc_library for the things
in //modules to make sure something in //src doesn't depend on
anything in //modules, for example.
The following succeeds:
bazel build //modules/skparagraph:skparagraph --config=clang \
--shaper_backend=harfbuzz_shaper --with_icu
As does `make bazel_canvaskit_debug` in //modules/canvaskit
Suggested Review Order:
- third_party/BUILD.bazel for ICU and harfbuzz rules. Pay
special attention to the genrules used to call the python
script for turning the icu .dat file into .S or .cpp.
- bazelrc and bazel/ for new flags and defines that control
use of ICU and harfbuzz. Unlike GN, with the public_defines
that get added in automatically if icu or harfbuzz is
depended upon, we need to set the defines at the top level.
This necessity might go away if we change the atoms to
depend on //modules/skshaper, which could define that flag.
- Top level BUILD.bazel files in //modules/skparagraph,
//modules/skshaper, //modules/skunicode, //modules/canvaskit
- All other .bazel file changes are automatic.
Bug: skia:12541
Change-Id: I38a9e0a9261d7e142eeb271c2ddb23f362f91473
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/478116
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
To make the atomic rules a bit easier to work with, in many
of the folders, this adds in cc_library rules to group
together the sources from that folder (and subfolders
where prudent). We only needs sources because those atoms
should have their headers as deps.
One issue that was pointed out is that there is currently
no way to restrict the inclusion of certain packages,
a la, `gn check`. For example, there is no mechanism from
stopping a dev from adding
#include "modules/canvaskit/WasmCommon.h"
to something in //src/core (except circular dependencies).
We can probably address that using Bazel's visibility
rules as needed:
https://docs.bazel.build/versions/main/visibility.htmlhttps://docs.bazel.build/versions/main/be/functions.html#package_group
It is recommended to look at this CL patchset by patchset.
PS1: Update gazelle command to generate rules in more folders.
PS2: A few changes to make generation work better.
PS3: The result of running make generate in //bazel
PS4: Adding the rules to build sksllex, the simplest binary I
could find in the Skia repo.
PS5: Adding the rules to build skdiff, a more complex binary.
I tried a few approaches, but ended up gravitating back
towards the layout where we have each folder/package
group up the sources. I imagine at some point, we'll have
skdiff depend on skia_core or something, which will
have things like //src/core, //src/codecs, //src/pathops
all bundled together.
PS7: Added in the groupings of sources, similar to what we had
earlier. I liked these for readability. These helped fix
up the //:skia_core build, and by extension, the CanvasKit
build.
Change-Id: I3faa7c4e821c876b243617aacf0246efa524cbde
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/476219
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
This new image filter constructor enables SkRuntimeEffects to be
used as shaders within the ImageFilter DAG. The shader is created
lazily using the SkRuntimeShaderBuilder enabling the resulting
shader to consume the previous stage of the ImageFilter graph.
This relands commit ad9d774c1f after
fixing the threading issue found by the TSAN bot.
Change-Id: I06dc4cf6a304b14804c55531a5bc3f2afa34e219
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/477156
Auto-Submit: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit ad9d774c1f.
Reason for revert: Task Test-Debian10-Clang-NUC7i5BNK-GPU-IntelIris640-x86_64-Release-All-DDL3_TSAN has been failing since this CL landed.
Original change's description:
> Add public API support for SkImageFilters::RuntimeShader
>
> This new image filter constructor enables SkRuntimeEffects to be
> used as shaders within the ImageFilter DAG. The shader is created
> lazily using the SkRuntimeShaderBuilder enabling the resulting
> shader to consume the previous stage of the ImageFilter graph.
>
> Change-Id: I5d6917e34a8e5fdd053399f15a1e2cc7409e686f
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/470459
> Reviewed-by: Brian Osman <brianosman@google.com>
> Reviewed-by: Michael Ludwig <michaelludwig@google.com>
> Commit-Queue: Derek Sollenberger <djsollen@google.com>
Change-Id: I0367a5c480df109c6116eb168792fe3c2fc58807
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/475644
Auto-Submit: Leandro Lovisolo <lovisolo@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Leandro Lovisolo <lovisolo@google.com>
This adds a simple go program to test the installed go
toolchain, and a Make rule to codify the arguments to
our gazelle binary, built with extensions.
I could not figure out how to get the .json file to work
with the gazelle() Bazel rule, but this works ok for now.
Bug: skia:12541
Change-Id: I5067b15c7518951aeb69559d3871799d3b5745f4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/475716
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
This uses the gazelle extension from
https://skia-review.googlesource.com/c/buildbot/+/473357
Review Tips:
- Ignore any changes to .h or .cpp files. Those have been
pulled out into their own CLs.
- Start with bazel/macros.bzl.
- Read the CL with the generation code, if you haven't already.
- Look at third_party/file_map_for_bazel.json.
- See experimental/bazel_test for an idea of how a cc_binary
would be made.
- Spot check one or two of the BUILD.bazel files.
This CL generates the "atomic" rules for src/, include/ and
modules/skshaper, as a starting point.
`bazel build --config clang //include/...` works
`bazel build --config clang //src/...` starts compiling,
(which verifies that the BUILD.bazel files are all valid),
but runs into errors because not all third_party deps have
been resolved, and there are some files missing from the
toolchain still (e.g. EGL headers).
Change-Id: Ib7e0fb0efdb9f08655f06cbc56e9bb4cf416294b
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/474240
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
This new image filter constructor enables SkRuntimeEffects to be
used as shaders within the ImageFilter DAG. The shader is created
lazily using the SkRuntimeShaderBuilder enabling the resulting
shader to consume the previous stage of the ImageFilter graph.
Change-Id: I5d6917e34a8e5fdd053399f15a1e2cc7409e686f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/470459
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Derek Sollenberger <djsollen@google.com>
Change-Id: Ibeea56ebd5dce53af1252ca3ecf6cc6f010bd461
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/469902
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
These rules can be used to build our GMs on WASM+WebGL and
libskia.a with just the CPU backend (and most other features
turned off).
This can be done with the following commands:
- bazel build //modules/canvaskit:gm-bindings-wasm --gpu_backend=gl_backend --with_gl_standard=webgl_standard
- bazel build :skia-core --config clang
This pivots slightly from http://review.skia.org/463517
by using config_settings [1] instead of platforms for
the optional features that we control. This pivot was
suggested in [2]
We have BUILD.bazel files in many of the subdirectories
that specify filegroups for the appropriate files. In
an effort to make //BUILD.bazel more readable, it is
the responsibility of these subfolders to deal with
conditionally including certain .h or .cpp files.
This is done using select statements and config_settings
or platform constraints as necessary.
For example, src/gpu/BUILD.bazel will different private
filegroups for each of the supported gpu backends [3]
and a more-visible filegroup called "srcs" that has
the right selection of the private files to be used
for compilation.
An effort has been made to avoid using glob() in our
BUILD.bazel files. These file lists were made by using
`ls -1` and some regex to add in quotes. We might want
to make a helper script to assist with that, if necessary.
To specify which options we have, the settings in
//bazel/common_config_settings/BUILD.bazel have been
redesigned. They make use of a macro `string_flag_with_values`
that removes the boilerplate. Patchset 36 shows what the
file looks like w/o the macro.
The top level BUILD.bazel file will still need to use
some logic to handle defines, because local_defines is
a list of strings, not a list of labels [4].
Suggested Review Order:
- WORKSPACE.bazel to see the new dependencies on the
emsdk toolchain and bazel_skylib
- bazel/common_config_settings/* to see the few settings
defined (we have more to define, see BUILD.gn and
//gn/skia.gni for ideas)
- BUILD.bazel to see the "skia-core" cc_library rule.
See also "gms" and "tests"
- modules/canvaskit/BUILD.bazel to see the use of
the emscripten "wasm_cc_binary" rule, which depends
on the "skia-core", "gms", and "tests" rule. Note that
it only builds some of the gms as a proof of concept.
- The other BUILD.bazel files. Some of these are not
platform or feature dependent (e.g. pathops). Others
are (e.g. gpu).
- All other files.
[1] https://docs.bazel.build/versions/4.2.1/skylark/config.html#user-defined-build-settings
[2] https://github.com/emscripten-core/emsdk/pull/920
[3] In this CL, that's just the webgl one.
[4] https://docs.bazel.build/versions/main/be/c-cpp.html#cc_library.local_defines
Change-Id: Ieecf9c106d5e3a6ae97d13d66be06b4b3c207089
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/458637
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
Owners-Override: Kevin Lubick <kjlubick@google.com>
This lets clients access and use the same RGB to YUV matrices that we
use internally.
Inspired by https://crrev.com/c/3223983
Bug: skia:12545
Change-Id: I7f70f56e721819c3d33da447eff2e572b7774c51
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/461476
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This reverts commit 65967ab2c9.
Reason for revert: used in Android - http://screen/3fk6K3RUWZG8x5f
Original change's description:
> Remove SkRuntimeShader::makeImage.
>
> We don't have any known users, and it no longer exposes anything that
> a user can't just do directly.
>
> Change-Id: Id653a6be3f265a2847b1670f3e6c054cf2d094a2
> Bug: skia:12482
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/453142
> Auto-Submit: John Stiles <johnstiles@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: John Stiles <johnstiles@google.com>
Bug: skia:12482
Change-Id: I6cc2e79796f53c42e9f53b7d9927c853e7e2d71c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/453317
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Owners-Override: Kevin Lubick <kjlubick@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
We don't have any known users, and it no longer exposes anything that
a user can't just do directly.
Change-Id: Id653a6be3f265a2847b1670f3e6c054cf2d094a2
Bug: skia:12482
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/453142
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Android has been updated to use fChild, so fIndex is dead.
Change-Id: Iec728aa91a4ad47f84e2188ade75f639f0c6087c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/447186
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>
We take advantage of their shared SkFlattenable lineage to store all
three types of object in the same sk_sp, and check their
Flattenable type to distinguish between them. Accessors allow us to
mimic the coding style of having three distinct fields.
Change-Id: I16426377f10fa2abffbf09bb7998c968614433df
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/435019
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>
Runtime shaders, color filters, and blenders are all able to sample from
a blender. These use the blend-function signature; both a src-color and
dst-color must be passed to sample. i.e.: sample(blender, s, d)
Change-Id: I3738e6b0b4af6d1d79e62ca1815c80d6a1ae9d6f
Bug: skia:12257
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/432056
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The preexisting enum versions now are just shallow factories for
the new blender versions, though internally we've kept the
specializations on impl.
Change-Id: I3449682bb443a4ff9f53cc7b0860343c56e377e4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/424436
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This will allow runtime blenders to leverage existing color filters or
shaders when computing a blend.
Change-Id: I743d5fc6d83a92cd190cb6bfd1c79789d8be2089
Bug: skia:12249
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/430658
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>
fChildren in the Builder is now a vector of ChildPtrs instead of a
vector of one particular type of child. This gives builder.child() the
flexibility to accept a color-filter, shader, or any other type that a
ChildPtr can hold.
Change-Id: I9e1ecf51aab1c74a9a15738bee7900b0c690ce9a
Bug: skia:11813
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/431196
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
It's still accessible internally (and by default when using
SkMakeRuntimeEffect), but we don't want clients using this.
If we can come up with a simple and consistent coordinate
model that doesn't expose implementation details, we'll
revisit this.
Change-Id: I77726830480a286541ae887f9cd9822eb10ea913
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/430422
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
... to aid in removing special ArithmeticImageFilter.
Can we use something like this to reimpl the ArithmeticImageFilter
--> BlenderImageFilter?
I see some special checking in filterBounds for ArithIF -- is that
required? Is that generalizable for any BlenderImageFilter?
If we can generalize blend[er]imagefilter, let's just move this
logic into Chrome -- no need for Arithmetic to appear in Skia
in any form!
Re: https://skia-review.googlesource.com/c/skia/+/424436
Change-Id: Ifa0ff2fa25de6385f6f60505e73ecc28463a80b3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/424417
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
We still need *a* copy, to satisfy SkSL that mutates the input color
parameter, but it almost never needs to be global, unless there are
calls to sample() from a function other than main.
With that tweak, we generate much better SkSL/GLSL code from every one
of our effects, avoiding the proliferation of global variables.
Bug: skia:12140
Change-Id: I5c3bd42df34a095969abcbbc60e69c653a08087a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/424299
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit 2fa843abc2.
Reason for revert: Oops, SkSL error in the ES2 path.
Original change's description:
> Convert GrDitherEffect to a runtime FP
>
> Includes a change so that we can create non-ES2 runtime effects, even
> outside of tests/tools. It's still locked to a private API, so clients
> can't access the functionality.
>
> Change-Id: Ie0643da2071bd223fccf05b35f3a7b6f7bbc4876
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/423578
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
TBR=bsalomon@google.com,brianosman@google.com,ethannicholas@google.com,michaelludwig@google.com
Change-Id: Icff68da3cadd00868c94b84fbb39e470a7bf45d0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/424100
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Includes a change so that we can create non-ES2 runtime effects, even
outside of tests/tools. It's still locked to a private API, so clients
can't access the functionality.
Change-Id: Ie0643da2071bd223fccf05b35f3a7b6f7bbc4876
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/423578
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Change-Id: I98fcaa0e83e574cdbdd767abbedcf6763c0fdce4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/422521
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
When writing runtime FPs, this lets us confirm that we're going to get
the constant output for constant input optimization.
Change-Id: I358507585423e5b15c92a0b2e9278b16f8727fe8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/419798
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This is a reland of 6034941cc2
Original change's description:
> Add SkRuntimeBlender class.
>
> This class is returned by SkRuntimeEffect::makeBlender when a runtime
> blend is returned. SkRuntimeBlendBuilder is also added as a convenience
> class to simplify creation and uniform setup.
>
> Our ability to add tests is limited in this CL because the SkPaint does
> not contain an SkBlender yet. We do have one test which builds an
> SkBlender, but there's not much we can do with it. Testing will be
> bulked up in the next CL.
>
> Change-Id: Ib2d7d04186690ec0d2238fc990a19d9e6b786ce3
> Bug: skia:12080
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/417006
> Commit-Queue: John Stiles <johnstiles@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
Bug: skia:12080
Change-Id: Ie41be141ba3787452f9d5c72946ebc748a5d6176
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/419160
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit 6034941cc2.
Reason for revert: breaking MSVC build
Original change's description:
> Add SkRuntimeBlender class.
>
> This class is returned by SkRuntimeEffect::makeBlender when a runtime
> blend is returned. SkRuntimeBlendBuilder is also added as a convenience
> class to simplify creation and uniform setup.
>
> Our ability to add tests is limited in this CL because the SkPaint does
> not contain an SkBlender yet. We do have one test which builds an
> SkBlender, but there's not much we can do with it. Testing will be
> bulked up in the next CL.
>
> Change-Id: Ib2d7d04186690ec0d2238fc990a19d9e6b786ce3
> Bug: skia:12080
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/417006
> Commit-Queue: John Stiles <johnstiles@google.com>
> Auto-Submit: John Stiles <johnstiles@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
TBR=brianosman@google.com,johnstiles@google.com
Change-Id: Id916f7458b827cbfdbc951c8f02aed16e2f44935
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:12080
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/419159
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
This class is returned by SkRuntimeEffect::makeBlender when a runtime
blend is returned. SkRuntimeBlendBuilder is also added as a convenience
class to simplify creation and uniform setup.
Our ability to add tests is limited in this CL because the SkPaint does
not contain an SkBlender yet. We do have one test which builds an
SkBlender, but there's not much we can do with it. Testing will be
bulked up in the next CL.
Change-Id: Ib2d7d04186690ec0d2238fc990a19d9e6b786ce3
Bug: skia:12080
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/417006
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This does basic plumbing work, but lacks a real implementation for the
custom blend subclass. That subclass is added in the followup CL of this
CL chain.
Change-Id: I8db0eb42737a739b49741ffd6f4a283a2c0a9d62
Bug: skia:12080
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/417005
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Like SkColorFilter, SkShader, etc., this has a public-facing component
(SkBlender) and a private subclass (SkBlenderBase) which can be
obtained via a helper function (as_BB). At present there are no public-
facing methods, but the type needs to be exposed to be usable by the
outside world.
These classes exist for SkRuntimeEffect to subclass. The blender base
provides a `program` method with the parameters that blending will use.
Change-Id: I75c772fd4108a9c21fbda84201a8b23d3750a0df
Bug: skia:12080
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/416916
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I17c624e9145d7152f65695ca3ce4592a11bb09a2
Bug: skia:12080
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/418637
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Needs more testing, but includes a GM that demonstrates the ultimate
benefit of this: our 3D color LUT demo working as a color filter.
Bug: skia:11813
Change-Id: I97c129c54bcf2cb788c0806b5d9e907ff058bb69
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/406296
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Runtime Blend effects always take two input colors--source and
destination--instead of one. This CL adds a new ProgramKind for blend
effects, a new program module (empty for now), and adds a test to
confirm that the signature for blend functions is checked. Currently
these are only accessible via skslc; there's no Runtime Effect API to
create one and the dest color isn't hooked up to anything.
Change-Id: I5272a811d2d76b878cfdf3429efa78c9c8b3fd97
Bug: skia:12080
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/416798
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
All callsites moved to the new templated GrSkSLFP factory
Change-Id: If8d0419379c96b5a52b2576a5da1b0a3da8cccbf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/415916
Auto-Submit: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Salomon <bsalomon@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>
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>
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 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>
