It's only used by a couple unit tests. We have other ways of getting
the same quality testing of our ref-count code now (e.g. TSAN).
BUG=skia:
CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu-GCC-x86_64-Release-CMake-Trybot,Build-Mac10.9-Clang-x86_64-Release-CMake-Trybot
Review URL: https://codereview.chromium.org/1408213005
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
Drawing with SkRect::MakeLargest() isn't actually working.
This appears to work correctly, and even be correct.
(It's a case explicitly handled by SkCanvas::onDrawPath).
BUG=skia:
Review URL: https://codereview.chromium.org/1411303002
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
imgblur is intended to establish a ground truth for debugging mask blur issues. It performs a brute force (non-separable) Gaussian blur of the provided image.
The blur code itself is in sk_tools_utils so it can be more easily used programmatically in other places (e.g., blur unit tests).
Review URL: https://codereview.chromium.org/1384203002
Now, that we are subsetting, fX0 is not necessarily less than
fSrcWidth (since fSrcWidth is really the subset width).
Ex: We may want a 10 pixel subset starting twenty pixels from the
left edge. In that case, fX0=20 and fSrcWidth=10.
Let's rename the width as fSubsetWidth to avoid confusion
and remove the check.
BUG=skia:
Review URL: https://codereview.chromium.org/1407603003
Iterating through the 903K skps that represent the
imagable 1M top web pages triggers a number of
bugs, some of which are addressed here.
Some web pages trigger intersecting cubic
representations of arc with their conic
counterparts. This exposed a flaw in coincident
detection that caused an infinite loop. The loop
alternatively extended the coincident section and,
determining the that the bounds of the curve pairs
did not overlap, deleted the extension.
Track the number of times the coincident detection
is called, and if it exceeds an empirically found
limit, assume that the curves are coincident and
force it to be so.
The loop count limit can be determined by enabling
DEBUG_T_SECT_LOOP_COUNT and running all tests. The
largest count is reported on completion.
Another class of bugs was caused by concident
detection duplicating nearly identical points that
had been merged earlier. To track these bugs, the
'handle coincidence' code was duplicated as a
const debug variety that reported if one of a
dozen or so irregularities are present; then it is
easier to see when a block of code that fixes one
irregularity regresses another.
Creating the debug const code version exposed some
non-debug code that could be const, and some that
was experimental and could be removed. Set
DEBUG_COINCIDENCE to track coincidence health and
handling.
For running on Chrome, DEBUG_VERIFY checks the
result of pathops against the same operation
using SkRegion to verify that the results are
nearly the same.
When visualizing the pathops work using
tools/pathops_visualizer.htm, set
DEBUG_DUMP_ALIGNMENT to see the curves after
they've been aligned for coincidence.
Other bugs fixed include detecting when a
section of a pair of curves have devolved into
lines and are coincident.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1394503003
This is a follow up to:
https://codereview.chromium.org/1401283003/
Supply separate flags for onBuildTileIndex
Since png and jpeg's implementations of onBuildTileIndex rely on
modifications to their underlying libraries, rather than whether we are
running on Android, use separate flags that can be disabled
independently.
This will allow us to easily turn off the feature. It also is a step
towards building and running on other platforms for testing (e.g.
valgrind/ASAN to find memory leaks etc).
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/fc06e9c0e621744654e231ae6fa4460d88c0e27e
Review URL: https://codereview.chromium.org/1402783008
