SkAlphaThresholdFilter was always allocating a mask texture
of the same size as the source texture. In addition to
potentially wasting VRAM, this could cause the mask to be
offset from the source texture, if the resulting bounds
were a different size than the source texture.
The fix is to allocate a mask texture only as large as the
bounds, and to offset it to the bounds origin on draw.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1609573002
Review URL: https://codereview.chromium.org/1609573002
The GPU fast path was not doing the correct thing for input bitmaps of
differing sizes. This change brings the fast path in line with the
slow path: use the union of foreground and background bounds as bounds,
offset the draw context by the bounds translation, and translate the
foreground and background independently by their respective offsets.
Finally, we add a texture domain for the background fragment
processor, since we may access texels outside its domain.
Note: this adds two new test cases to the xfermodeimagefilter GM, so
those will need to be rebaselined.
BUG=568196
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1588633002
Review URL: https://codereview.chromium.org/1588633002
If the input bitmap passed to SkTileImageFilter does not fill the
srcRect, we were tiling this incorrectly (see the first sample
from tileimage filter -- it draws from a srcRect of 12,12 50x50
to a dstRect of 0,0 50x50. There should be no tiling at all
in this case!)
In order to fix this, we need to pad the bitmap out to srcRect,
and tile with that. In order to tile correctly in the GPU case,
we need to request a tileable texture.
NOTE: this will change the results of the tileimagefilter GM (correctness,
and added src / dest rects).
BUG=skia:4774
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1570133003
Review URL: https://codereview.chromium.org/1570133003
Make SkAutoTMalloc's interface look more like SkAutoMalloc:
- add free(), which does what you expect
- make reset() return a pointer fPtr
No public API changes (SkAutoTMalloc is in include/private)
BUG=skia:2148
Review URL: https://codereview.chromium.org/1516833003
Use an inline function that does a normal shift. When built for the sanitizer, add casts so that the shift is unsigned.
Also make a few fixes to do unsigned shifts or avoid the shift altogether; and add an argument spec to some macros.
R=reed@google.com,mtklein@google.com
BUG=skia:4633
Review URL: https://codereview.chromium.org/1503423003
Make each filter responsible for expanding its destination
bounds. Previously, we were using a union of all
intermediate bounds sizes via join() calls in many image
filters' computeFastBounds(), due to the fact that those
filters could only produce bitmaps the same size as their
inputs. Now, we compute optimal bounds for each filter as
follows:
1) Pass the (unmodified) clip bounds to the root node
of the DAG in the first recursive call to onFilterImage()
as the Context's fClipBounds.
2) Reverse-map the clip: when recursing up the DAG in
filterInput[GPU](), apply filter-specific expansion to the
clip by calling calling onFilterNodeBounds(... kReverse).
This allows upstream nodes to have a clip that respects the
current node's requirements. This is done via helper
function mapContext().
3) Forward-map the source bitmap: just prior to applying
the crop rect in applyCropRect(), we determine the filter's
preferred bounds by mapping the source bitmap bounds
forwards via onFilterNodeBounds(..., kForward).
NOTE: GMs affected by this change:
fast_slow_blurimagefilter: fast and slow paths now produce the same result
spritebitmap: drawSprite() and drawBitmap() paths now produce the same result
filterfastbounds: fast bounds are optimized; all drop-shadow results now appear
apply-filter: snug and not-snug cases give same results
dropshadowimagefilter: drawSprite() results now show shadows
draw-with-filter: no artifacts on erode edges; blur edges no longer clipped
displacement, imagefiltersbase, imagefiltersclipped, imagefilterscropexpand, imagefiltersscaled, matriximagefilter,
resizeimagefilter, localmatriximagefilter, testimagefilters: fixed incorrect clipping
imagefilterstransformed, morphology: no artifacts on erode edges
BUG=skia:1062,skia:3194,skia:3939,skia:4337,skia:4526
Review URL: https://codereview.chromium.org/1308703007
Because the convolution kernel is (currently) applied in device space,
there's no way to know which object-space pixels will be touched. So
return false from canComputeFastBounds().
The results from the matrixconvolution GM were actually wrong, since
they were showing edge differences on the clip boundaries, where they
should really only show on crop boundaries. I added a crop to the GM
to keep the results the same (which are useful to test the different
convolution tile modes).
While I was at it, SkImageFilter::affectsTransparentBlack() was
inapplicable on most things except color filters, and its use on
leaf nodes was confusing. So I removed it, and made
SkImageFilter::canComputeFastBounds() virtual instead.
BUG=skia:4630
Review URL: https://codereview.chromium.org/1500923004
Reason for revert:
Introduced memory leak; pixel changes in Chrome.
Original issue's description:
> Matrix convolution bounds fix; affectsTransparentBlack fixes.
>
> Because the convolution kernel is (currently) applied in device space,
> there's no way to know which object-space pixels will be touched. So
> return false from canComputeFastBounds().
>
> The results from the matrixconvolution GM were actually wrong, since
> they were showing edge differences on the clip boundaries, where they
> should really only show on crop boundaries. I added a crop to the GM
> to keep the results the same (which are useful to test the different
> convolution tile modes).
>
> While I was at it, SkImageFilter::affectsTransparentBlack() was
> inapplicable on most things except color filters, and its use on
> leaf nodes was confusing. So I removed it, and made
> SkImageFilter::canComputeFastBounds() virtual instead.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/8705ec80518ef551994b82ca5ccaeb0241d6adecTBR=reed@google.com,reed@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1497083005
Because the convolution kernel is (currently) applied in device space,
there's no way to know which object-space pixels will be touched. So
return false from canComputeFastBounds().
The results from the matrixconvolution GM were actually wrong, since
they were showing edge differences on the clip boundaries, where they
should really only show on crop boundaries. I added a crop to the GM
to keep the results the same (which are useful to test the different
convolution tile modes).
While I was at it, SkImageFilter::affectsTransparentBlack() was
inapplicable on most things except color filters, and its use on
leaf nodes was confusing. So I removed it, and made
SkImageFilter::canComputeFastBounds() virtual instead.
BUG=skia:
Review URL: https://codereview.chromium.org/1500923004
Also remove the SK_SUPPORT_LEGACY_LINEAR_GRADIENT_TABLE guard since it is no
longer used in Chromium.
BUG=chromium:563492
R=reed@google.com,mtklein@google.com
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review URL: https://codereview.chromium.org/1489233005
The crop rect should be applied to the union of the input bounds, not
to the src input's bounds. These are often the same, since the saveLayer
offscreen size is computed as the union of all the required bounds, but
is not correct if the input primitive is not used (e.g., if all inputs
are connected to SkImageSources). But this will change as we
move to more accurate intermediate bounds computations (getting rid of the join() hacks as described in skbug.com/3194).
Since we can't know this without actually processing the inputs,
split SkMergeImageFilter processing into:
- filter all inputs
- applyCropRect to the union'ed bounds
- allocate the destination
- do the merge
BUG=3194
Review URL: https://codereview.chromium.org/1475793002
This CL still keeps the weird diamond shape we have for all our ProgramBuilders.
However, the GrGLSL base class will allow us to pull multiple other parts
of our program setup away from GL which will eventually allow us to break up
the diamond.
As part of this all ShaderBuilder subclass have been made gl independent,
however I will move them to GLSL files/class names in a follow on CL.
BUG=skia:
Review URL: https://codereview.chromium.org/1416423003
This is the GPU equivalent of https://codereview.chromium.org/1415653003/.
It requires passing down the bounds of the crop rect (srcBounds), and
turning the blur 3-patch optimization in convolve_gaussian() into a 5-patch:
clear above and below srcBounds, blur with bounds checks inside left and
right rects, blur without bounds checks in middle rect.
Note: this change causes minor pixels diffs in the
imagefilterscropexpand GM: for odd crop positions relative to the
dstBounds, we are now correctly resampling at an even pixel boundary.
BUG=skia:4502, skia:4526
Committed: https://skia.googlesource.com/skia/+/c57e0ded7d535523cfc6bf07c78e5f3479bb8c42
Review URL: https://codereview.chromium.org/1431593002
Reason for revert:
Causing valgrind error. Looks like the issue is in conolve_gaussiand_2d where bounds is not getting set if there is no srcBounds, but later on that bounds is being read in the creation of a TextureDomain.
Original issue's description:
> Make SkBlurImageFilter capable of cropping during blur (GPU path).
>
> This is the GPU equivalent of https://codereview.chromium.org/1415653003/.
>
> It requires passing down the bounds of the crop rect (srcBounds), and
> turning the blur 3-patch optimization in convolve_gaussian() into a 5-patch:
> clear above and below srcBounds, blur with bounds checks inside left and
> right rects, blur without bounds checks in middle rect.
>
> Note: this change causes minor pixels diffs in the
> imagefilterscropexpand GM: for odd crop positions relative to the
> dstBounds, we are now correctly resampling at an even pixel boundary.
>
> BUG=skia:4502, skia:4526
>
> Committed: https://skia.googlesource.com/skia/+/c57e0ded7d535523cfc6bf07c78e5f3479bb8c42TBR=bsalomon@google.com,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:4502, skia:4526
Review URL: https://codereview.chromium.org/1407133019
- remove float -> int conversion, keeping float -> byte
- remove support for doubles
I was thinking of specializing Sk8f for AVX. This will help keep the complexity down.
This may cause minor diffs in radial gradients: toBytes() rounds where castTrunc() truncated. But I don't see any diffs in Gold.
https://gold.skia.org/search2?issue=1411563008&unt=true&query=source_type%3Dgm&master=false
BUG=skia:4117
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review URL: https://codereview.chromium.org/1411563008
This is the GPU equivalent of https://codereview.chromium.org/1415653003/.
It requires passing down the bounds of the crop rect (srcBounds), and
turning the blur 3-patch optimization in convolve_gaussian() into a 5-patch:
clear above and below srcBounds, blur with bounds checks inside left and
right rects, blur without bounds checks in middle rect.
Note: this change causes minor pixels diffs in the
imagefilterscropexpand GM: for odd crop positions relative to the
dstBounds, we are now correctly resampling at an even pixel boundary.
BUG=skia:4502, skia:4526
Review URL: https://codereview.chromium.org/1431593002
Reason for revert:
failing on msaa
Original issue's description:
> Revert[2] of "stop using drawSprite (at least w/ no filters) as it is going away"
>
> Fixed assert in test that was calling GrRecordReplaceDraw(). That function now uses
> drawBitmap, so updated the test to check for that (instead of drawSprite).
>
> This reverts commit 21b7663470.
>
> BUG=skia:
> TBR=
>
> Committed: https://skia.googlesource.com/skia/+/7b81994d95f10cda80ddb85af68a2651ff31782f
TBR=
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1420053009
Fixed assert in test that was calling GrRecordReplaceDraw(). That function now uses
drawBitmap, so updated the test to check for that (instead of drawSprite).
This reverts commit 21b7663470.
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1410343011
We compute a lot of { srcRect, dstRect } pairs in this
code, but they're always the same width and height, and
dstRect often has a zero origin. So pass only one or
the other and an offset, where required. Among other
things, this simplifies the code in convolve_gaussian(),
since we only have to 3-patch the dstRect.
BUG=skia:4502
Review URL: https://codereview.chromium.org/1430593006
SkBlurImageFilter can currently only process a source image
which is larger than or equal to the destination rect. If
the source image (or crop rect) is smaller, it is padded
out to dest size with transparent black via the 6-param
version of applyCropRect().
Fixing this requires modifying all the flavours of RGBA
box_blur() to accept a src crop rect.
BUG=skia:4502, skia:4526
CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-GCC-Nexus5-CPU-NEON-Arm7-Release-Trybot;client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Committed: https://skia.googlesource.com/skia/+/1b82ceb737c73327412f2e8a91748481e1aec9e4
Review URL: https://codereview.chromium.org/1415653003
Reason for revert:
ASAN failures (see https://codereview.chromium.org/1415653003/)
Original issue's description:
> Make SkBlurImageFilter capable of cropping during blur (raster path)
>
> SkBlurImageFilter can currently only process a source image
> which is larger than or equal to the destination rect. If
> the source image (or crop rect) is smaller, it is padded
> out to dest size with transparent black via the 6-param
> version of applyCropRect().
>
> Fixing this requires modifying all the flavours of RGBA
> box_blur() to accept a src crop rect.
>
> BUG=skia:4502, skia:4526
> CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-GCC-Nexus5-CPU-NEON-Arm7-Release-Trybot;client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
>
> Committed: https://skia.googlesource.com/skia/+/1b82ceb737c73327412f2e8a91748481e1aec9e4TBR=mtklein@google.com,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:4502, skia:4526
Review URL: https://codereview.chromium.org/1428053002
SkBlurImageFilter can currently only process a source image
which is larger than or equal to the destination rect. If
the source image (or crop rect) is smaller, it is padded
out to dest size with transparent black via the 6-param
version of applyCropRect().
Fixing this requires modifying all the flavours of RGBA
box_blur() to accept a src crop rect.
BUG=skia:4502, skia:4526
CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-GCC-Nexus5-CPU-NEON-Arm7-Release-Trybot;client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review URL: https://codereview.chromium.org/1415653003
In order to have a central pinch point for bitmap allocation, change all
filters to use Proxy::createDevice() instead of allocating memory
directly with SkBitmap::tryAllocPixels().
This will aid in moving filter backing stores and caches to
discardable memory.
BUG=skia:
Review URL: https://codereview.chromium.org/1414843003
Reason for revert:
re-land once layout test have been disabled (so they can be rebased)
Original issue's description:
> Update feSpotLight to match spec
>
> This change updates feSpotLight to match the spec via two changes:
>
> 1) specularExponent is ignored if the spotlight has no coneAngle (GPU
> bug only). This change updates the GPU path so that it matches the
> CPU path and the spec in this regard.
>
> 2) specularExponent is clamped to the 1-128 range. The spec does not
> specify a clamp for the specularExponent attribute of feSpotLight.
> Note that the spec *does* specify this clamp for the
> specularExponent attribute of feSpecularLighting. It looks like we
> incorrectly applied this to both specularExponent attributes.
>
> This change (along with a parallel change in Blink) allows us to pass
> the SVG filter effects conformance test here:
> http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObject/filters-light-01-f.html
>
> Additionally, this brings our behavior in line with Safari and Edge’s
> behavior on this filter.
>
> Two new cases were added to gm/lighting.cpp to catch these issues:
> - The existing spotlight case exercised the path where our specular
> exponent was between 1-128 and had a limiting cone angle.
> - The first new spotlight case exercises the path where our specular
> exponent is between 1-128 and we do not have a limiting cone angle.
> - The second new spotlight case exercises the path where the specular
> exponent is not within the 1-128 range, to ensure that we don’t
> incorrectly clip to this range.
>
> BUG=472849
>
> Committed: https://skia.googlesource.com/skia/+/c84ccb070258db2803a9e8f532bfe7239a737063TBR=senorblanco@google.com,senorblanco@chromium.org,bsalomon@google.com,ericrk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=472849
Review URL: https://codereview.chromium.org/1417463006
This change updates feSpotLight to match the spec via two changes:
1) specularExponent is ignored if the spotlight has no coneAngle (GPU
bug only). This change updates the GPU path so that it matches the
CPU path and the spec in this regard.
2) specularExponent is clamped to the 1-128 range. The spec does not
specify a clamp for the specularExponent attribute of feSpotLight.
Note that the spec *does* specify this clamp for the
specularExponent attribute of feSpecularLighting. It looks like we
incorrectly applied this to both specularExponent attributes.
This change (along with a parallel change in Blink) allows us to pass
the SVG filter effects conformance test here:
http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObject/filters-light-01-f.html
Additionally, this brings our behavior in line with Safari and Edge’s
behavior on this filter.
Two new cases were added to gm/lighting.cpp to catch these issues:
- The existing spotlight case exercised the path where our specular
exponent was between 1-128 and had a limiting cone angle.
- The first new spotlight case exercises the path where our specular
exponent is between 1-128 and we do not have a limiting cone angle.
- The second new spotlight case exercises the path where the specular
exponent is not within the 1-128 range, to ensure that we don’t
incorrectly clip to this range.
BUG=472849
Review URL: https://codereview.chromium.org/1403403003
premultiplied colors, however the flag for whether or not to do this,
which is present in their parent filters, is dropped when creating the
GL implementations. This change adds logic to forward the value from
the parent filter to the GL implementation.
This makes GPU behavior match software and fixes a WebKit
LayoutTest. See referenced bug.
BUG=473186
Review URL: https://codereview.chromium.org/1410553002
