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
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
Needed to enlarge radii to surface bugs without exceeding max texture size on low end devices.
BUG=chromium:477684
Review URL: https://codereview.chromium.org/1508003008
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
When the parallel stroke to the curve can't be computed from
the intersection of the tangent lines, as straight line connects
the two points instead. Allow the intersection to succeed unless
the ratio isn't finite or the contribution of (1 - ratio) isn't
significant.
R=reed@google.com,fmalita@chromium.org
BUG=skia:4603
Review URL: https://codereview.chromium.org/1484873003
If the client wants no caching, and we haven't already cached it, pass the
caller's dst-buffer directly down to the generator, avoiding the (previous)
extra memcpy.
BUG=skia:4594
Review URL: https://codereview.chromium.org/1473373002
This shouldn't really make any difference but allocating and holding on to a GrRenderTarget for each test target generates image differences for Mali GPUs. This CL allows an existing render target to be used for the test target.
TBR=bsalomon@google.com
Review URL: https://codereview.chromium.org/1447113002
Makes it so that the oversized-texture/bmp case doesn't run on the CPU and makes it so that the subrect rendered is adjacent to the texture pad area on the bottom/right edges.
Review URL: https://codereview.chromium.org/1424473006
This allows internal Gr texture creation code to succeed for extraneous textures while running the bleed GM. This means we can turn on the shader variants.
Review URL: https://codereview.chromium.org/1418473004
An additional positive of this CL is that GrGLShaderBuilder is now GL independent besides GrGLProgramBuilder
BUG=skia:
Review URL: https://codereview.chromium.org/1431433003