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>
Original review here: https://skia-review.googlesource.com/c/2990/
Changes since:
- simpler implementations of load_tail() / store_tail(): slower, but more obviously correct to all compilers
- fleshed out math ops on Sk8i and Sk8u to make unit tests happy on -Fast bot (where we always have AVX2)
- now storing stage functions as void(*)() to avoid undefined behavior and/or linker problems. This restores 32-bit Windows.
- all AVX2 Sk8x methods are marked always-inline, to avoid linking the "wrong" version on Debug builds.
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=3064
Change-Id: Id0ba250037e271a9475fe2f0989d64f0aa909bae
Reviewed-on: https://skia-review.googlesource.com/3064
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This reverts commit I1c82e5755d8e44cc0b9c6673d04b117f85d71a3a.
Reason for revert: lots of failing bots.
TBR=mtklein@chromium.org,msarett@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I653bed3905187f43196504f19424985fa2a765b5
Reviewed-on: https://skia-review.googlesource.com/3063
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
The interior antialiasing was causing a small transparent rectangle in the middle of filled rects
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3062
Change-Id: If0bf26b96c8969af6d81f3a3d6fee59e8c1d747e
Reviewed-on: https://skia-review.googlesource.com/3062
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Bench runtime changes:
sRGB: 7194 -> 3735 = 1.93x faster
F16: 6531 -> 2559 = 2.55x faster
Instead of building 4x and 1-3x pipelines and then maybe 8x and 1-7x, instead build either the short ones or the long ones, but not both. If we just take care to use a compatible run_pipeline(), there's some cross-module type disagreement but everything works out in the end.
Oddly, a few places that looked like they'd be faster using SkNx_fma() or Sk4f_round()/Sk8f_round() are actually faster the long way, e.g. multiply, add 0.5, truncate. Curious! In all the other places you see here that I've used SkNx_fma(), it's been a significant speedup.
This folds in a couple refactors and cleanups that I've been meaning to do. Hope you don't mind... if find the new code considerably easier to read than the old code.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2990
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Change-Id: I1c82e5755d8e44cc0b9c6673d04b117f85d71a3a
Reviewed-on: https://skia-review.googlesource.com/2990
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This doesn't compute the correct distance vector but it suffices for gaussian edges.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2986
Change-Id: I8bd9e37b0f3788c30d85c95a3c0845d093f22554
Reviewed-on: https://skia-review.googlesource.com/2986
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This will fix the Vulkan orientation when the screen is rotated by having
the compositor do the corrections for us. However, it is suggested in the
Android Vulkan docs that for power reasons it may be better for the app
to get the needed rotation off of the VkAndroidSurface and then manually
adjust for this rotation in the rendering without the compositor doing any
corrections. This is something we can look into a later date as it would
require sending some info back from the VulkanWindowContext back to Skia
about what Matrix should be applied.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3052
Change-Id: I4d3d620ffcc77e607fce8d06b869c2912a61400c
Reviewed-on: https://skia-review.googlesource.com/3052
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Every type now nominally has Load4() and Store4() methods.
The ones that we use are implemented.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3046
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Change-Id: I7984f0c2063ef8acbc322bd2e968f8f7eaa0d8fd
Reviewed-on: https://skia-review.googlesource.com/3046
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Error out when fuzzing
conditions are met.
Also, make degenerate
input line ends consistent.
TBR=reed@google.com
BUG=653452, 626164, skia:5829
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3048
Change-Id: I23a01adde9dec07b54d66ab2418b3ea0b96e4456
Reviewed-on: https://skia-review.googlesource.com/3048
Commit-Queue: Cary Clark <caryclark@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
In this function, it first check whether this arc is a lone point
or not. If not, it converts angles to unit vectors. The problem
here is that when the radius is huge and the sweepAngle is small,
the function angles_to_unit_vectors() could return a startV ==stopV.
When that happens, it will draw a dot at the point that corresponding
to the startAngle. This CL adds a special branch for this case, and
draw a connecting line between the points at startAngle and endAngle.
BUG=640031, skia:5807
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2388833002
Review-Url: https://codereview.chromium.org/2388833002
Add support for tight bounds to detect and return moveTo
followed by close or zero-length lineTo.
Also short circuit so that hard work is avoided when
the path bounds is also the tight bounds.
Avoid doing work if the bounds can be trivially computed.
Include naked moveTo coordinates in the tight bounds.
R=fmalita@chromium.org
BUG=skia:5555, skia:5553
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2394443004
Review-Url: https://codereview.chromium.org/2394443004
