We aren't consistent about this but having it at 4 seems to be causing style churn in code I've been editting recently. Also I prefer something other than 4 so that initalizers don't align with the constructor body.
BUG=skia:
Change-Id: I6ae850c34324e792dfd717f449634abcc7be010b
Reviewed-on: https://skia-review.googlesource.com/6030
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
I believe TextureType is vestigial
Change-Id: I253f3a3200d6e05d5e0204662225f4a8e8ed5cb9
Reviewed-on: https://skia-review.googlesource.com/6029
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This is a staging CL to position the writePixels in sw_draw_with_mask_filter to be moved to GrSurfaceContext
Change-Id: I808372d30ad4aca4a56125ea75d071f7a3747146
Reviewed-on: https://skia-review.googlesource.com/5926
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
These are proving useful in the read/write-Pixels migration
Change-Id: I297f31968362d205977b769808320b1dc06249df
Reviewed-on: https://skia-review.googlesource.com/5936
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This reverts commit 8ba64d1996.
Reason for revert: does not appear to have been blocking the roll.
Original change's description:
> Revert "SkNx basically always is fast now."
>
> 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>
>
TBR=mtklein@chromium.org,reviews@skia.org,fmalita@chromium.org,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I230dd4c2abb2d14ffc302be5376b9eaacbbeafcc
Reviewed-on: https://skia-review.googlesource.com/6026
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
This reverts commit 2e018f548d.
Reason for revert: doesn't appear to have been the roll problem.
Original change's description:
> Revert "clamp to premul when reading premul sRGB"
>
> This reverts commit 04e10da836.
>
> Reason for revert: roll?
>
> Change-Id: Id0a8dcd62763bd6eddde120c513ca97e098a4268
> Reviewed-on: https://skia-review.googlesource.com/6022
> Commit-Queue: Mike Klein <mtklein@chromium.org>
> Reviewed-by: Mike Klein <mtklein@chromium.org>
>
TBR=mtklein@chromium.org,reviews@skia.org,brianosman@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I399ca5e728ce6766c6707682c4c6b685681ffdeb
Reviewed-on: https://skia-review.googlesource.com/6025
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
This reverts commit 398487a850.
Reason for revert: See if this is causing the roll failure
Original change's description:
> Add a deferred copy surface (take 2)
>
> 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>
>
TBR=bsalomon@google.com,robertphillips@google.com,brianosman@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I1ef40f0d5fb0bca62031f94f10eb18acd753e913
Reviewed-on: https://skia-review.googlesource.com/6024
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This reverts commit 04e10da836.
Reason for revert: roll?
Change-Id: Id0a8dcd62763bd6eddde120c513ca97e098a4268
Reviewed-on: https://skia-review.googlesource.com/6022
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
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>
