In some legacy situations users of SkRefCnt subclasses were keeping
the objects alive with a reference count of 0. Now that these users are
cleaned up, remove the hack which allowed such code to keep functioning.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3264
Change-Id: I22f63d87b6d995cad6326998284930ad9eaa2983
Reviewed-on: https://skia-review.googlesource.com/3264
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
The shader leaves its color in r,g,b,a, so to implement this color filter, we move {r,g,b,a} into {dr,dg,db,da}, then load the filter's color in {r,g,b,a}, then apply the xfermode as usual.
I've left a note about how we could sometimes cut a stage for some xfermodes. Similarly we really only need to move_src_dst instead of swap_src_dst, but it seemed handy and less error prone to do a full two way swap. As usual, we can always circle back and fine-tune these things if we want.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3243
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Change-Id: I928c0fb25236eb75cf238134c6bebb53af5ddf07
Reviewed-on: https://skia-review.googlesource.com/3243
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Matt Sarett <msarett@google.com>
We now require SSSE3, SSE4.1, SSE4.2, AVX, F16C, AVX2, and FMA compiler support on x86. This lone workaround for missing SSSE3 support is incongruous. It's also unlikely that there's any x86 compiler that supports C++11 but not SSSE3, certainly none we care about.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3244
Change-Id: Ie83f5ebb3f214eec726fedd0df6f46e72f735f38
Reviewed-on: https://skia-review.googlesource.com/3244
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Original review here: https://skia-review.googlesource.com/c/2990/
Second attempt here: https://skia-review.googlesource.com/c/3064/
This is the same as the second attempt, but with the change to SkOpts_hsw.cpp left out.
That omitted part is the key piece... this just lands the refactoring.
CQ_INCLUDE_TRYBOTS=master.client.skia:Perf-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-ASAN-Trybot,Perf-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-GN,Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot,Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-Fast-Trybot;master.client.skia.compile:Build-Win-MSVC-x86_64-Debug-Trybot
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3242
Change-Id: Iaafa793a4854c2c9cd7e85cca3701bf871253f71
Reviewed-on: https://skia-review.googlesource.com/3242
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
The Vulkan backend already stored a GrVkRT, but was inconsistent
in sometimes using the stored value and sometimes the passed in
value (though they should be the same). This just cleans up the
code so that everyone uses a stored RT.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3126
Change-Id: I571de4bfb1da612d61171321d5224a9a19d8e545
Reviewed-on: https://skia-review.googlesource.com/3126
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
In the screenspace AA tessellator, a path's fill types would be applied
twice: once when extracting contours, and then again when filling polys.
It was supposed to be forced to kWinding_FillType by the second call to
mesh_to_polys(), but for hysterical reasons this parameter is unused!
For kInverseWinding_FillType (the only mode where this actually caused a bug),
I unwittingly papered over the problem by reversing the outer contour for the
inverse fill types, and comparing against -1 instead of 1.
The better fix is to actually pass a winding mode of kWinding_FillType
to polys_to_triangles(), and remove the (ignored) param from mesh_to_polys().
Then we can pass a clockwise outer contour as before, and compare
against 1 instead of -1.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2404403003
Review-Url: https://codereview.chromium.org/2404403003
I haven't explicitly confirmed this, but it's likely that today's r12b -> r13 upgrade made this possible.
CQ_INCLUDE_TRYBOTS=master.client.skia.compile:Build-Ubuntu-Clang-mipsel-Debug-GN_Android-Trybot,Build-Ubuntu-Clang-mipsel-Release-GN_Android-Trybot
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3241
Change-Id: I4d19ad48f387d48e0fa4a9f1637c67eb6e1ba4ae
Reviewed-on: https://skia-review.googlesource.com/3241
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
I think I'm now at the point of needing to just resolve missing symbols.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3201
Change-Id: Ib908bd72c23f2d4bafd17182eedcb2fc85c422e5
Reviewed-on: https://skia-review.googlesource.com/3201
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Prints thermal trip points that have been exceeded when a
HardwareException is raised, and verbosity is set to debug. This can
help us correlate thermal trip points with throttling and detect
future throttling before it occurs.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2408893002
Review-Url: https://codereview.chromium.org/2408893002
In 32-bit land, VkFence is uint64_t, so reinterpret_cast (between two
identical integral types) is illegal.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3143
Change-Id: Iba9507f5678f647710f4abd35023c192bf6eed66
Reviewed-on: https://skia-review.googlesource.com/3143
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Clang detection is specific to GCC-like toolchains.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3171
Change-Id: I7144bc8e5cd3e774625b51a6dda981284ed1fdc1
Reviewed-on: https://skia-review.googlesource.com/3171
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
The libc++ include paths have changed very slightly. I've left GN compatible with both older r12 NDKs and the new r13 to smooth the transition.
The libc++ in r13 depends on long-double math.h functions (cosl, atanl, etc.) only available in Android API v21 (Lollipop) and up. That's what the 64-bit bots were already on, so we just pull the 32-bit bots up to the same target. Conveniently, the oldest bots we have (N7 and N10) are on Lollipop.
The r13 MIPS64 sysroots are a little weird... /usr/include and /usr/lib64 but no /usr/lib. That'd be fine---we only want 64-bit builds---but Clang searches for /usr/lib64 via its path to /usr/lib, and without at least an empty /usr/lib, it can't find /usr/lib64. So you'll see a special mips64el section in the GN config where we do this all manually (other platforms pick this all up correctly from --sysroot). I've chosen to do this rather than fix it up in the asset create.py scripts so that we stay compatible with vanilla NDKs, which is convenient for developers.
CQ_INCLUDE_TRYBOTS=master.client.skia.compile:Build-Mac-Clang-arm64-Debug-GN_Android-Trybot,Build-Ubuntu-Clang-arm-Debug-GN_Android-Trybot,Build-Ubuntu-Clang-arm-Release-GN_Android-Trybot,Build-Ubuntu-Clang-arm64-Debug-GN_Android-Trybot,Build-Ubuntu-Clang-arm64-Debug-GN_Android_FrameworkDefs-Trybot,Build-Ubuntu-Clang-arm64-Debug-GN_Android_Vulkan-Trybot,Build-Ubuntu-Clang-arm64-Release-GN_Android-Trybot,Build-Ubuntu-Clang-mips64el-Debug-GN_Android-Trybot,Build-Ubuntu-Clang-mips64el-Release-GN_Android-Trybot,Build-Ubuntu-Clang-mips64el-Release-GN_Android-Trybot,Build-Ubuntu-Clang-mipsel-Debug-GN_Android-Trybot,Build-Ubuntu-Clang-mipsel-Release-GN_Android-Trybot,Build-Ubuntu-Clang-x64-Debug-GN_Android-Trybot,Build-Ubuntu-Clang-x64-Release-GN_Android-Trybot,Build-Ubuntu-Clang-x86-Debug-GN_Android-Trybot,Build-Ubuntu-Clang-x86-Release-GN_Android-Trybot
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3180
Change-Id: I6f3b5d9411ded0ee49c1099490f41fa86a8736f8
Reviewed-on: https://skia-review.googlesource.com/3180
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This would've caught the incorrect distances in the center bug
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3111
Change-Id: I9461a8865b561cc139a18a5e779e933d7979ee0d
Reviewed-on: https://skia-review.googlesource.com/3111
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
When sampling, we previously had to figure out the number of rows that
were written to the output based on the value reported by
incrementalDecode. (We also messed up the first time - see the fix in
crrev.com/2343153003.)
Instead, make incrementalDecode report the actual number of rows
written to. This can be provided directly to fill.
Make SkPngCodec report the correct number of rows, by incrementing its
count when it actually writes to the destination.
This also will simplify my in progress GIF change.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2407543002
Review-Url: https://codereview.chromium.org/2407543002
This reverts commit Id0ba250037e271a9475fe2f0989d64f0aa909bae.
crbug.com/654213
Looks like Chrome Canary's picking up Haswell code on non-Haswell machines.
Change-Id: I16f976da24db86d5c99636c472ffad56db213a2a
Reviewed-on: https://skia-review.googlesource.com/3108
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
allRowsCallback was asserting that
rowNum - fFirstRow == fLinesDecoded
But it was expecting fFirstRow to be 0 (logically, it is, since we are
decoding all rows), and it never set it (because it doesn't really need
to, except for this assert). This is only a problem if we reuse an
SkPngCodec after previously scaling with it. Add a test that triggers
the assert, and fix it.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2401133002
Review-Url: https://codereview.chromium.org/2401133002
Much less copy-pasted code, fewer implementation details leaking out,
and going to be easier to extend for 4f and color space testing.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2900
Change-Id: Icc468c606aa35fbe82c64bcc398e7e348e0faa20
Reviewed-on: https://skia-review.googlesource.com/2900
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Brian Osman <brianosman@google.com>
