This reverts commit 21f7838296.
Reason for revert: roll?
Original change's description:
> SkNx basically always is fast now.
>
> We had this SKNX_IS_FAST hanging around from before Chrome always built with NEON.
>
> CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
>
> Change-Id: Ia5cc0323b3ef052192e2903f961aee11eb3f82d8
> Reviewed-on: https://skia-review.googlesource.com/5946
> Commit-Queue: Mike Klein <mtklein@chromium.org>
> Reviewed-by: Mike Reed <reed@google.com>
> Reviewed-by: Florin Malita <fmalita@chromium.org>
>
TBR=mtklein@chromium.org,fmalita@chromium.org,reed@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I0e57285c68eae0a64213fe29ea4cca5519777954
Reviewed-on: https://skia-review.googlesource.com/6040
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
This reverts commit eeb7137a0b.
Reason for revert: well, duh, I guess we'd better update the GYP and Google3 builds...
Original change's description:
> Do not build the ktx encoder for android framework
>
> Move SkKTXImageEncoder.cpp into an optional block, and disable that
> block for the android framework. Use a new define to determine whether
> to define the entry point, rather than using
> SK_BUILD_FOR_ANDROID_FRAMEWORK.
>
> Change-Id: I41103459135af744cf5715f27783c63dc37a7ad1
> Reviewed-on: https://skia-review.googlesource.com/5982
> Commit-Queue: Leon Scroggins <scroggo@google.com>
> Commit-Queue: Mike Klein <mtklein@chromium.org>
> Reviewed-by: Mike Klein <mtklein@chromium.org>
>
TBR=mtklein@chromium.org,mtklein@google.com,scroggo@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I8da75db31884b5148f7f85a6a0c3e6913b71cfa8
Reviewed-on: https://skia-review.googlesource.com/6021
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
BUG=668550
Change-Id: Ic771818bd5a4a46b83fdb82b69b98cb6b93a23a2
Reviewed-on: https://skia-review.googlesource.com/5697
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Move SkKTXImageEncoder.cpp into an optional block, and disable that
block for the android framework. Use a new define to determine whether
to define the entry point, rather than using
SK_BUILD_FOR_ANDROID_FRAMEWORK.
Change-Id: I41103459135af744cf5715f27783c63dc37a7ad1
Reviewed-on: https://skia-review.googlesource.com/5982
Commit-Queue: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
It's pretty easy to start with sound premultiplied linear floats, pack those to sRGB encoded bytes, then read them back to linear floats and find them not quite premultiplied, with a color channel just a smidge greater than the alpha channel. This can happen basically any time we have different transfer functions for alpha and colors... sRGB being the only one we draw into.
This is an annoying problem with no known good solution. So apply the clamp hammer.
These new calls on SkRasterPipeline should make it impossible to get wrong.
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Change-Id: I4c974f4a7b151f3f684946f1e83d06b1b288fd01
Reviewed-on: https://skia-review.googlesource.com/5945
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
We had this SKNX_IS_FAST hanging around from before Chrome always built with NEON.
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Change-Id: Ia5cc0323b3ef052192e2903f961aee11eb3f82d8
Reviewed-on: https://skia-review.googlesource.com/5946
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
This CL forces all GrSurface copies to go through a GrSurfaceContext (rather than GrContext).
There is a bit of goofiness going on here until read/writePixels is also consolidated in GrSurfaceContext and a proxy-backed SkImage/SkSurface is added.
This is a reland of https://skia-review.googlesource.com/c/5773/ (Add a deferred copy surface)
Change-Id: Ide560f569aede5e622420dc2f30eef76357d69f4
Reviewed-on: https://skia-review.googlesource.com/5939
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Change-Id: Iff7f63635cdbc5cc51e5968a565f2fde2be3acb0
Reviewed-on: https://skia-review.googlesource.com/5932
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
BUG=skia:
Change-Id: Iaf016ef914d1e292fd175f71d91129b85e3caca7
Reviewed-on: https://skia-review.googlesource.com/5934
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Brian Osman <brianosman@google.com>
BUG=skia:
Change-Id: I65705a6142a96a476c2d9eae79aeaaa29ade2dde
Reviewed-on: https://skia-review.googlesource.com/5928
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
This reverts commit 4431de6af9.
Reason for revert: ANGLE errors (at the very least)
Original change's description:
> Add a deferred copy surface
>
> This CL forces all GrSurface copies to go through a GrSurfaceContext (rather than GrContext).
>
> There is a bit of goofiness going on here until read/writePixels is also consolidated in GrSurfaceContext and a proxy-backed SkImage/SkSurface is added.
>
> Change-Id: Iab1867668d8146a766201158a251b9174438ee2b
> Reviewed-on: https://skia-review.googlesource.com/5773
> Reviewed-by: Brian Osman <brianosman@google.com>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
> Commit-Queue: Robert Phillips <robertphillips@google.com>
>
TBR=bsalomon@google.com,robertphillips@google.com,brianosman@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I61408d9e306b9b1ab32f93ab086e95184e12857f
Reviewed-on: https://skia-review.googlesource.com/5938
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
The more I look at std::unordered_map and co., the less I like them.
I think we might want to bet on SkTHash*.
As a simple first improvement, add move support.
Next comes shrinking, and then I'll start moving over SkTDynamicHash users.
BUG=skia:6053
Change-Id: Ifdb5d713aab66434ca271c7f18a0cbbb0720099c
Reviewed-on: https://skia-review.googlesource.com/5943
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Hal Canary <halcanary@google.com>
This CL forces all GrSurface copies to go through a GrSurfaceContext (rather than GrContext).
There is a bit of goofiness going on here until read/writePixels is also consolidated in GrSurfaceContext and a proxy-backed SkImage/SkSurface is added.
Change-Id: Iab1867668d8146a766201158a251b9174438ee2b
Reviewed-on: https://skia-review.googlesource.com/5773
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Follow on to 5860. When computing left and top, divide by the sample
size directly rather than using get_scaled_dimension, which promotes
0 to 1, potentially moving the area to clear outside the bounds of
the image.
BUG=skia:6046
Change-Id: I87c3fe88fadb400743174af9f9a277acd4fbc279
Reviewed-on: https://skia-review.googlesource.com/5924
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
The flag has been removed from Chromium.
R=reed@google.com,
TBR=
Change-Id: Ibccada2068d29b019660be46f5f5797331719a57
Reviewed-on: https://skia-review.googlesource.com/5648
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Update sk_64_smul_check to detect the numeric_limits<int64_t>::min()
case (which cannot be safely passed to SkTAbs), and fail.
BUG=skia:6019
R=reed@google.com,mtklein@google.com
Change-Id: I5f252be7e9377d3261f992b53f2b893899cbe960
Reviewed-on: https://skia-review.googlesource.com/5863
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
BUG=skia:6049
Change-Id: I90d06f9bb3d6180a0921130b9fe523733211e481
Reviewed-on: https://skia-review.googlesource.com/5849
Commit-Queue: Eric Boren <borenet@google.com>
Reviewed-by: Ravi Mistry <rmistry@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
When clearing due to SkCodecAnimation::RestoreBGColor_DisposalMethod,
intersect the frameRect with the image size to prevent clearing outside
the bounds of the allocated memory.
Add a test image, created by the fuzzer.
BUG=skia:6046
Change-Id: I43676d28f82abf093ef801752f3a9e881580924c
Reviewed-on: https://skia-review.googlesource.com/5860
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Now that SkNWayCanvas inherits from SkNoDrawCanvas, we need to
override onDrawDrawable().
BUG=skia:
Change-Id: Id8cf62f5675199202580d3ee94c71a0ae231c81e
Reviewed-on: https://skia-review.googlesource.com/5865
Commit-Queue: Derek Sollenberger <djsollen@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
BUG=skia:
Change-Id: Ib3e5b53fc0f01ad00cab94e1130324d7b901ed77
Reviewed-on: https://skia-review.googlesource.com/5791
Commit-Queue: Eric Boren <borenet@google.com>
Reviewed-by: Ravi Mistry <rmistry@google.com>
Delete no-longer-used parts of swarming module and add "pragma: no
cover" where applicable.
BUG=skia:
Change-Id: I0f516d7be520a4d4b4efbfa97bd383a5f124e713
Reviewed-on: https://skia-review.googlesource.com/5790
Reviewed-by: Ravi Mistry <rmistry@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
Add SkCanvas::setBoundRect, which sets the max clip rectangle,
which can be replaced by clipRect, clipRRect and clipPath.
BUG=skia:
Change-Id: Ie39eb1715214971576e7a1dda760c6997a7e0208
Reviewed-on: https://skia-review.googlesource.com/5359
Commit-Queue: Stan Iliev <stani@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
I want to land this so we can start testing color space aware
decoding on Android. In particular, it will be interesting to
see how linear premultiplication will affect existing content.
This will only modify BitmapRegionDecoder behavior. I'll
follow up with a similar change to BitmapFactory.cpp in Android.
This will cause image diffs on Gold.
BUG=skia:
Change-Id: Iffda5f035447f2608ce26945570b503f8971b735
Reviewed-on: https://skia-review.googlesource.com/5698
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
To avoid undefined int underflow behavior.
BUG=skia:6017
R=mtklein@google.com,reed@google.com
Change-Id: Ib707ad5e1d87eda70525c56db14849c4164c5640
Reviewed-on: https://skia-review.googlesource.com/5861
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Rather than auto-adding the Job, assert that it's listed. This enforces
that the JOBS list is accurate. Add all missing compile Jobs to the list.
BUG=skia:
Change-Id: Ic7a90165ccac36baa52a4674798977021d6812d7
Reviewed-on: https://skia-review.googlesource.com/5848
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Eric Boren <borenet@google.com>
Don't walk off the end if the loop doesn't
contain the expected value.
R=kjlubick@google.com
BUG=skia:6047
Change-Id: I96815180dc7c92b45691037ae6c4b40beedc009a
Reviewed-on: https://skia-review.googlesource.com/5845
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Cary Clark <caryclark@google.com>
Prior to this CL, if a GIF file was truncated before reading the local
color map of a frame, incremental decode would do the wrong thing. In
onStartIncrementalDecode, we would either create a color table based on
the global color map, or we would create a dummy one with only one
color (transparent). The dummy color table is correct if there is
neither a global nor a local color map, and allows us to fill the frame
with transparent. But if more data is provided, and it includes an
actual color map and image data, one of the following can happen:
- If the created color table is smaller than the actual one, the
decoded data may include indices outside of the range of the created
color table, resulting in a crash.
- If we get lucky, and the created color table is large enough, it may
still be the wrong colors (and most likely is).
To solve this, make onStartIncrementalDecode fail if there is a local
color map that has not been read yet. A future call may read more data
and read the correct color map.
This is done by returning kIncompleteInput in
SkGifCodec::prepareToDecode if there is a local color map that has not
yet been read. (It is possible that there is no color map at all, in
which case we still need to support decoding that frame. Skip
attempting to decode in that case.)
In onGetPixels, if prepareToDecode returned kIncompleteInput, return
kInvalidInput. Although the input is technically incomplete, no future
call will provide more data (unlike in incremental decoding), and there
is nothing interesting for the client to draw. This also prevents
SkCodec from attempting to fill the data with an SkSwizzler, which has
not been created. (An alternative solution would be create the dummy
color table and an SkSwizzler, which would keep the current behavior.
But I think the new behavior of returning kInvalidInput makes more
sense.)
Add tests to verify the intended behavior:
- getPixels fails.
- startIncrementalDecode fails, but after providing more data it will
succeed and incremental decoding matches the image decoded from the
full stream.
- Both succeed if there is no color table at all.
Change-Id: Ifb52fe7f723673406a28e80c8805a552f0ac33b6
Reviewed-on: https://skia-review.googlesource.com/5758
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This reverts commit ce33f10677.
Reason for revert: Breaking many gpu bots
Change-Id: I94c813ed6a9311458c872f74bb1b0792f46ff414
Reviewed-on: https://skia-review.googlesource.com/5737
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Tool will now check for and output all unsuccessfully parsed ICC
profiles in input sksp images if --testColorCorrectionSupported is set
as a flag. All ICC-aware codecs had to be slightly modified in order to
expose this information, as the logic for accessing the ICC profiles is
all within the codecs. If --writeFailedImages is set, it will also
output all images whoses ICC profiles were not supported.
TBR=reed@google.com
BUG=skia:
Change-Id: Ic310d82bdebf92f8d3bc0ad3dcc688136b6de377
Reviewed-on: https://skia-review.googlesource.com/5355
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Robert Aftias <raftias@google.com>
BUG=skia:6048
Change-Id: I86abfc0059c6523db08e552df16e88ae71379ed7
Reviewed-on: https://skia-review.googlesource.com/5733
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Eric Boren <borenet@google.com>
Instead of relying on cpu-features.c, just do what it does.
Good reading: http://man7.org/linux/man-pages/man3/getauxval.3.html
While it's nice to use the headers when possible, should either of these headers not be available, we can fall back to doing it all manually:
extern "C" uint32_t getauxval(uint32_t)
static const int AT_HWCAP = 16;
static const int HWCAP_CRC32 = (1<<7);
To keep things simple I've slimmed cpu feature detection down to just the features we actually make use of. This removes all runtime feature detection for ARMv7... we expect NEON to be globally available, and so far we haven't used the other FMA/FP16 bits on ARMv7. ARMv8 feature dection remains the same, CRC32 before, CRC32 after. x86 (cpuid-based detection) and MIPS (nothing) are untouched.
We need to keep //third_party/cpu-features for //third_party/libwebp.
Change-Id: I6c96df9a09ae68c8c0e54c1152aa177ba9bafc83
Reviewed-on: https://skia-review.googlesource.com/5800
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This is a precursor to using mask load, mask store, and gather instructions for f16. This is a slight performance win too, through slightly simpler code generation. Having done this, it now makes sense to give a name to f16->f32 conversion, from_f16().
Finally, while we're at this, also send store_f32 through store(), so that now all formats use load, gather, and store uniformly.
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Change-Id: I403f16f712936e2bcf3294e72c863cb6c6fbcf0c
Reviewed-on: https://skia-review.googlesource.com/5731
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
in response to 5784
Change-Id: I3ad34a30743e7ffbd04767668c288a4f884eb19c
Reviewed-on: https://skia-review.googlesource.com/5732
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
We were always already supplying this, makes it simpler
BUG=skia:
Change-Id: I36ac35205df5ab2a0fb7ec26e83ddb1547154816
Reviewed-on: https://skia-review.googlesource.com/5778
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
