Epsilon bias to keep bitmap sample rounding consistent with geometry
rounding.
Also update the GM to draw an outer border + drop uninteresting
scales in favor of negative scale variants.
BUG=skia:4680,skia:4649
R=reed@google.com,caryclark@google.com,mtklein@google.com
Review URL: https://codereview.chromium.org/1527633002
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
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
The result is that the set of "generic" imagefilters (e.g. SkColorFilterImageFilter) that use drawing commands to return their results will now stay in the same domain as their src (i.e. gpu-src --> gpu-dst).
ApplyFilterGM exercises this, and now asserts this same-domain invariant.
BUG=skia:4467
Review URL: https://codereview.chromium.org/1401053003
This method is different from MatrixFilter, in that MatrixFilter does not require a pre-existing
filter, but LocalM does. Also change the comment to be more general, as there is no promise that
we return a different subclass, and certainly not a specific subclass.
This pattern of obj->newWithModifiers() also more closely matches the pattern in SkImage (newSubset).
BUG=skia:
Review URL: https://codereview.chromium.org/1402133002
At draw time, this filter simply concatenates the given matrix to the
CTM, and recurses on its input. The matrix is thus applied to any
upstream filter parameters and crop rects.
BUG=skia:
Review URL: https://codereview.chromium.org/1392833005
Result:
- clients can get a filtered version of an image without having to setup a temp drawing environment
- for some cases, the process is more efficient even than (deprecated) drawSprite, since there is no need to draw/copy the result
Impl:
- made Proxy virtual so we don't need to have an existing device to use it
This, in conjunction with LocalMatrixImageFilter, should allow us to simplify and optimize ApplyImageFilter() in cc/output/gl_renderer.cc
BUG=skia:
Review URL: https://codereview.chromium.org/1390913005
Migrating the flag to embedder defines (Chromium already guarded).
Also augment gradient-focused GMs to generate both dithered/undithered
results.
BUG=skia:4436
R=reed@google.com,robertphillips@google.com
Review URL: https://codereview.chromium.org/1400813006
Reason for revert:
Breaks Chrome with this link error: ../../third_party/skia/include/effects/SkMorphologyImageFilter.h:75: error: undefined reference to 'SkMorphologyImageFilter::SkMorphologyImageFilter(int, int, SkImageFilter*, SkImageFilter::CropRect const*)'
../../third_party/skia/include/effects/SkMorphologyImageFilter.h:104: error: undefined reference to 'SkMorphologyImageFilter::SkMorphologyImageFilter(int, int, SkImageFilter*, SkImageFilter::CropRect const*)'
Presumably due to code in third_party/WebKit/Source/platform/graphics/filters/FEMorphology.cpp that contains:
#include "SkMorphologyImageFilter.h"
...
if (m_type == FEMORPHOLOGY_OPERATOR_DILATE)
return adoptRef(SkDilateImageFilter::Create(radiusX, radiusY, input.get(), &rect));
return adoptRef(SkErodeImageFilter::Create(radiusX, radiusY, input.get(), &rect));
Original issue's description:
> factories should return baseclass, allowing the impl to specialize
>
> waiting on https://codereview.chromium.org/1386163002/# to land
>
> BUG=skia:4424
>
> Committed: https://skia.googlesource.com/skia/+/80a6dcaa1b757826ed7414f64b035d512d9ccbf8TBR=senorblanco@google.com,robertphillips@google.com,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:4424
Review URL: https://codereview.chromium.org/1389063002
The "zeroPath" and emptystroke GMs capture this issue.
This CL changes the following PDF GMs: emptystroke dashing4
lineclosepath dashing3 zeroPath linepath
complexclip3_complex complexclip3_simple roundrects
degeneratesegments filltypes strokerect pathfill
inverse_paths desk_chalkboard.skp
After this change, all PDF GMs look better (closer to 8888).
The dashing4, emptystroke, and zeroPath GMs still need a lot
of work to make them look right.
BUG=538726
Review URL: https://codereview.chromium.org/1374383004
drawImage calls now properly embeds the original jpeg.
NOTE: drawBitmap*() calls no longer embed JPEG files when
possible (this is in advance of eliminating bitmaps backed
by encoded data). Chromium has already moved from
drawBitmap to drawImage.
Comparisons:
control:
total PDF drawImage/drawBitmap calls: 8010
total PDF jpeg images: 0
total PDF regular images: 3581
experiament:
total PDF drawImage/drawBitmap calls: 8014
total PDF jpeg images: 271
total PDF regular images: 3311
total PDF regular images: 3582 (271 + 3311)
When comparing rendered output there were perceptual
differences in the following four GMs: colorcube, emboss,
colormatrix, and tablecolorfilter. All of these differences
were improvements (that is, closer to the 8888 rendering)
due fixing a bug with colorfilters and forgetting to call
notifyPixelsChanged.
No SKPs had perceptual differences.
Total PDF size dropped from 133964 kB to 126276 kB, a 5.7%
improvement (mostly due to restoring use of JPG images in
SKPs).
BUG=skia:4370
Review URL: https://codereview.chromium.org/1372783003
An alternative way of addressing this is to alter SkCanvas::drawRoundRect to just reject isEmpty (i.e., un-sorted or truly empty) input rects.
BUG=skia:3786
Review URL: https://codereview.chromium.org/1373293002
One side effect is that the SkShader's (or implicit shader's) fragment processor is responsible for the transition from an unpremul paint color to a premul color.
Review URL: https://codereview.chromium.org/1348583002
To avoid breaking existing SKPs, add a deserialization stub which
unflattens SkBitmapSource records to SkImageSources.
R=reed@google.com,mtklein@google.com,robertphillips@google.com
Review URL: https://codereview.chromium.org/1363913002
Previously annotations added between saveLayer/restore were lost.
Merge annotations in SkPDFDevice::drawDevice(). Also modified code to
apply correct transformation and clipping on annotations added between
saveLayer/restore:
- Apply the initial transform only when adding the annotations into the
doc, otherwise we need to unapply sub-device's initial transform
before merging the annotations into parent-device.
- Apply only device-local clipping. fClipStack is in global coordinates,
which is not suitable to clip rects in sub-devices.
BUG=skia:4080
BUG=503515
Review URL: https://codereview.chromium.org/1257533004
