SkImageFilters::Paint did not use every slot of the SkPaint, with only
its color, alpha, color filter, and shader having a meaningful effect on
the image filter result. It was always blended into a transparent dst,
so blend mode wasn't very relevant, and it was always filled to whatever
required geometry, so stroke style, path effect, and mask filters were
ignored or not well specified.
Color, alpha, and color filter can all be combined into an SkShader, so
a more constrained SkImageFilters::Shader provides the same useful
capabilities without as many surprises.
SkImageFilters::Paint still exists, but is deprecated to be removed
once I've confirmed clients aren't depending on it.
Bug: skia:9310
Change-Id: I11a82bda1a5d440726cf4e2b5bfaae4929568679
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/323680
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
This is part of a larger effort to force SkImage users to specify
the direct context they want to use when manipulating GPU images.
Chrome CL 2299194 (landed) enables the staging flag.
bug: skia:10466
Change-Id: I959db57dd8dca5c2622eb5ffaa7de161c4d6d8f0
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302643
Commit-Queue: Brian Salomon <bsalomon@google.com>
Auto-Submit: Adlai Holler <adlai@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Change-Id: Ifc0ab9c5c41cf139a5b6f79e29e6c0112d563667
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/274741
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
This makes SkCanvas::drawImage() consistent with the AutoLayerForImageFilter
that applies when the draw isn't a sprite, or if drawImageRect or drawRect
with an image-shader was used instead.
Bug: skia:9561
Change-Id: Ic395f580b06753706ddcaed832535ec4edb3bb5a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/274507
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
The performance regression only happened on iOS devices. Benchmarking
on Desktops or Android devices doesn't seem to show any significant
regressions.
Tested this on iPhone XS with nanobench and saw a 10ms->30ms regression:
regression:
61/63 MB 1 10.5ms 10.7ms 10.8ms 12.2ms 5% █▂▁▁▂▁▂▂▂▁ 8888 GM_savelayer_with_backdrop
101/101 MB 1 36ms 36.5ms 36.4ms 36.8ms 1% ▁▅▃▆▆▄▆▃▃█ gles GM_savelayer_with_backdrop
before regression:
61/63 MB 1 10.3ms 10.4ms 10.6ms 12.4ms 6% █▂▁▂▁▁▁▁▁▁ 8888 GM_savelayer_with_backdrop
96/96 MB 1 10.6ms 10.7ms 10.7ms 10.8ms 1% ▄▁▄▂▆█▅▃▂▅ gles GM_savelayer_with_backdrop
It's interesting to see that 8888 is always fast. Is the regressing CL changing blur from software to GPU?
Bug: https://github.com/flutter/flutter/issues/36064
Change-Id: Iea2305e41a31bd5b4267f45bfd835231d49d639a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/234413
Commit-Queue: Yuqian Li <liyuqian@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Bug: skia:9280
Change-Id: Ic7ca3a9c86025128bc45b89ea90aa4553287b8c9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/230879
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This almost gets gms to be iwyu clean. The last bit is around gm.cpp
and the tracing framework and its use of atomic. Will also need a way
of keeping things from regressing, which is difficult due to needing to
do this outside-in.
Change-Id: I1393531e99da8b0f1a29f55c53c86d53f459af7d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/211593
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Current strategy: everything from the top
Things to look at first are the manual changes:
- added tools/rewrite_includes.py
- removed -Idirectives from BUILD.gn
- various compile.sh simplifications
- tweak tools/embed_resources.py
- update gn/find_headers.py to write paths from the top
- update gn/gn_to_bp.py SkUserConfig.h layout
so that #include "include/config/SkUserConfig.h" always
gets the header we want.
No-Presubmit: true
Change-Id: I73a4b181654e0e38d229bc456c0d0854bae3363e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/209706
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Hal Canary <halcanary@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Change-Id: If0eb6fb2efb6816b92ad7ca7d8caaace71397b7f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/209409
Commit-Queue: Ravi Mistry <rmistry@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Auto-Submit: Mike Reed <reed@google.com>
Idea: transition callers to this, so we can later typedef SkColorFilter
and SkShader to the same thing.
Bug: skia:8937
Change-Id: I000c882e11622091aa44c141aa6ddd1216414f46
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/206685
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Reed <reed@google.com>
sk_tool_utils doesn't really fit the naming convention
the rest of code under tools/ tends to use.
Change-Id: I45326a174101c6eb4b6149e9c742f658f2fd23b1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/202313
Auto-Submit: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Rather that returning nullptr for a recording
canvas, return a raster canvas instead.
R=reed@google.com,robertphillips@google.com
Bug: skia:
Change-Id: I211d8ef368b9aec6d14cc72d1652ac6a03f3fa7b
Reviewed-on: https://skia-review.googlesource.com/151666
Commit-Queue: Cary Clark <caryclark@skia.org>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Should make it easier to ask just for images.
Change-Id: If821743dc924c4bfbc6b2b2d29b14affde7b3afd
Reviewed-on: https://skia-review.googlesource.com/82684
Commit-Queue: Hal Canary <halcanary@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
I was using 'source' where I should have said 'input'. Also, to be
consistent with other image filters, ensure that the input is in the
destination gamut before we start blurring.
BUG=skia:
Change-Id: I751961b42a2a5d110ee8ea8916279c8fe0d5248e
Reviewed-on: https://skia-review.googlesource.com/6486
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
- perform version check in CreateProc for XfermodeImageFilter and ArithmeticImageFilter
This reverts commit 3ed485f424.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2992
Change-Id: Ib4a154cdd5f5d1dcac921ef50d53b79a2d6a1be8
Reviewed-on: https://skia-review.googlesource.com/2992
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
In the current implementation, a blur filter is always created even in the
case when sigma.fX == 0 && sigma.fY == 0. This CL makes the blur filter
return input in this case.
BUG=568393
Review URL: https://codereview.chromium.org/1518643002
