No-Tree-Checks: true
Change-Id: Ibfbbfe35caf9e2ed8a80aa9add2c4cae50585120
Reviewed-on: https://skia-review.googlesource.com/120997
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: I6dd917c1f090a18e6508b0391f119f8f91929162
Reviewed-on: https://skia-review.googlesource.com/120502
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: Ic6408fdc8819342da175ec8b99b5838669b1b2ae
Reviewed-on: https://skia-review.googlesource.com/120501
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: Iafbcab2fd406a81766f534d70b36f38b1c369506
Reviewed-on: https://skia-review.googlesource.com/120500
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Change-Id: I36957b8d7d96ac262b509c218779775c90864314
Reviewed-on: https://skia-review.googlesource.com/120420
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: I0b0959063c22b2066b2103a4e93e396c10eb388e
Reviewed-on: https://skia-review.googlesource.com/120382
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: I8cfebed0a6617a625dd91e31af4b581aaeae86fe
Reviewed-on: https://skia-review.googlesource.com/120122
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: I8f567c475e8941ddb5d122dbb42c17413727021c
Reviewed-on: https://skia-review.googlesource.com/120184
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: I04894e17378cfbc982a11854a48217b63a2534ca
Reviewed-on: https://skia-review.googlesource.com/120161
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Adding roll.sh to make it easy.
Change-Id: I7887c5f9a41c5b68a5dec89ebc8ac86a1707fef6
Reviewed-on: https://skia-review.googlesource.com/120120
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: I3fe4e27e70270f4dc31610f98741c63b3574cf96
Reviewed-on: https://skia-review.googlesource.com/116628
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
The png.h header provides some macros and declarations from subincludes.
By default include-what-you-use will suggest using these subincludes
directly, but this was not the intent of png.h. This adds a mapping file
so that include-what-you-use knows that these subincludes are actually
private and png.h should be used instead.
Change-Id: Ibf9df6dbdbde0e657f6e548ed0e8f2310f44cfea
Reviewed-on: https://skia-review.googlesource.com/114481
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Bug: chromium:807324
Though these pngs are technically incorrect, many such PNGs exist, and
they are supported in Chromium. Ensure that users of SkCodec (e.g.
Android, Flutter) display them as well.
Change-Id: I2f1e573b4b7039cea81f96397cc0aa4cbc9461c3
Reviewed-on: https://skia-review.googlesource.com/111082
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Revert "use -isystem for headers from third_party"
This reverts commit 138bd155ed.
Revert "write -isystem paths relative to the build root"
This reverts commit 085bc52363.
I suspect the first breaks building on systems with an old libpng
or zlib installed, and the second definitely breaks GN -> CMake.
Change-Id: I5b29669b21b1444daeec8fb784337422ee17311a
Reviewed-on: https://skia-review.googlesource.com/110183
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
The default makes these system-absolute paths,
which confuses fiddle's overlay builds.
Now we should see things like,
-isystem ../third_party/externals/jsoncpp/include
where we previously had,
-isystem /Users/mtklein/skia/third_party/externals/jsoncpp/include
Change-Id: I7b161a550fdb95b06e17c372cd5bec3015e3c8b7
Reviewed-on: https://skia-review.googlesource.com/109382
Reviewed-by: Joe Gregorio <jcgregorio@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This supresses warnings from code in those headers,
e.g. warnings about switch case fallthrough in SDL_memset4(),
defined inline in SDL_stdinc.h.
Change-Id: I5341a67d4949b28ec5ffa6b7ae433748406e99db
Reviewed-on: https://skia-review.googlesource.com/109140
Reviewed-by: Hal Canary <halcanary@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This is a reland of 9d7a73527a.
Original change's description:
> remove third_party/etc1
>
> Nothing seems to reference it.
>
> Change-Id: Ib009a7dc33d31439b11588758015a07485f56eaa
> Reviewed-on: https://skia-review.googlesource.com/99861
> Reviewed-by: Mike Klein <mtklein@chromium.org>
> Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: I3a6428074896c7b3c80cb23db61f70d7cb0c785f
Reviewed-on: https://skia-review.googlesource.com/108460
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Bug: oss-fuzz:6299
Change-Id: I2e87368e04ff37db7e431fd1960f0bf91440037f
Reviewed-on: https://skia-review.googlesource.com/107281
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Change-Id: I9e3d82445bb26b98ff6a60dff28f9655cc9ea1fb
Reviewed-on: https://skia-review.googlesource.com/102624
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This reverts commit 9d7a73527a.
Reason for revert: still used by Fiber in Google3
Original change's description:
> remove third_party/etc1
>
> Nothing seems to reference it.
>
> Change-Id: Ib009a7dc33d31439b11588758015a07485f56eaa
> Reviewed-on: https://skia-review.googlesource.com/99861
> Reviewed-by: Mike Klein <mtklein@chromium.org>
> Commit-Queue: Mike Klein <mtklein@chromium.org>
TBR=mtklein@chromium.org,robertphillips@google.com
Change-Id: I12b950931f0680576faefd1907a26afe22cf680f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/100460
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Nothing seems to reference it.
Change-Id: Ib009a7dc33d31439b11588758015a07485f56eaa
Reviewed-on: https://skia-review.googlesource.com/99861
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This rolls skcms into skia and builds it in dev configurations.
We don't use it in any way yet, but if nothing else this gives
us roundabout Windows skcms build bots.
Bug: skia:7493
Change-Id: Idd945ccd5c7a543841d76ab600cc117f2ee074dc
Reviewed-on: https://skia-review.googlesource.com/99880
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This doesn't appear to have any effect.
It's not mentioned in our build configuration anywhere,
nor is third_party/libwebp/webp on any include path.
Bug: skia:4037
Change-Id: I41710fe5e82bb97946e64d5f975c09c8ba21dc0d
Reviewed-on: https://skia-review.googlesource.com/99860
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
These have been replaced by duration on the base class.
Change-Id: Id87ecf09f4da6840280e3f5657453915a8d3c81b
Reviewed-on: https://skia-review.googlesource.com/99245
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This rolls from 5.2.1 (2013) to 5.3.4 (2017).
I was looking at why the GomaNoFallback bot was failing,
and noticed that we had a static copy of Lua here instead
of a DEPS entry. This doesn't do anything to change the
GomaNoFallback situation.
Change-Id: Ia3cdca85551fe680b60b38cb8c5a8fb5349e177f
Reviewed-on: https://skia-review.googlesource.com/93120
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
For reference, the version number is pulled from:
chromium/src/third_party/llvm-build/cr_build_revision
This version of clang includes fixes for bugs in the latest
Windows 10 SDK headers.
Bug: skia:
Change-Id: Ieee6eb2dff2f98a2340a8433135b6c3f916c0577
Reviewed-on: https://skia-review.googlesource.com/82721
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
Bug: b/70203010
From https://github.com/libjpeg-turbo/libjpeg-turbo/commit/c308d434.
This commit fixes a bug in BitmapRegionDecoder, and is the tip of tree.
Rather than using our mirror, just pull in upstream directly. Move our
config files into third_party/libjpeg-turbo, so we can just DEPS to
upstream. These files are unchanged, except jconfig.h, where I added a
comment regarding arithmetic coding.
Add a test image which demonstrates the bug.
Change-Id: I00f8f961f69e407dc31ca6d15c66518aa0acbafd
Reviewed-on: https://skia-review.googlesource.com/81442
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This partially reverts commit
1793e7bb46.
Hide SkEncodedInfo
Bug: skia:7353
Bug: skia:6839
This contains information that is not necessary for clients to know. The
Color enum tells the number of components in the input, but this is only
interesting internally (to the SkSwizzler).
Similarly, the Alpha enum differs from SkAlphaType in that it has
kBinary instead of kPremul. This is useful information only internally
for determining whether the SkColorSpaceXform needs to premultiply.
The bitsPerComponent is potentially useful for a client; Android (in
SkAndroidCodec) uses it to determine the SkColorType. Rather than
exposing bitsPerComponent, make SkAndroidCodec a friend so it can
access the SkEncodedInfo. A future change will change SkCodec to
recommend F16 for bitsPerComponent > 8, but that will be more involved;
it was the reason for the revert of this CL.
Switch conversionSupported to use an SkColorType, which is enough info.
Replace the SkEncodedInfo::Alpha field on SkCodec::FrameInfo with an
SkAlphaType.
SkCodec still needs an SkEncodedInfo, so move its header (which is
already not SK_API) to include/private.
TBR=mtklein@chromium.org,reed@google.com
Change-Id: I928b1f55317602cb37d29da63b53026c8d139cee
Reviewed-on: https://skia-review.googlesource.com/80860
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This reverts commit c6f7a4ffa9.
Reason for revert: Causing differences in Gold, stemming from the fact that this changes the recommended SkImageInfo for 16 bits-per-component PNG from N32 to F16.
- an F16 bitmap already png-encodes to a 16 bits-per-component PNG, but it does not encode a linear colorspace (possibly a bug?). when we decode this PNG using getInfo(), it fails because it has an F16 color type and non-linear colorspace. (In the encode-srgb-png gm, this results in blank results for F16.) We could correct this on the encoder side, but it seems possible that a 16 bits-per-component PNG could be encoded with a different color space. In that case, we'd want SkCodec to recommend F16/SRGBLinear, but I think we'd want the SkCodec to store the encoded SkColorSpace so that we can Xform between the two. Currently SkCodec only stores one color space, so that will require a refactor.
- When decoding 16-bits-per-component PNGs, we are now decoding them to F16. This shows differences in Gold. The srgb/gpu results now look more like F16. I think this is fine.
Original change's description:
> Hide SkEncodedInfo
>
> Bug: skia:7353
> Bug: skia:6839
>
> This contains information that is not necessary for clients to know. The
> Color enum tells the number of components in the input, but this is only
> interesting internally (to the SkSwizzler).
>
> Similarly, the Alpha enum differs from SkAlphaType in that it has
> kBinary instead of kPremul. This is useful information only internally
> for determining whether the SkColorSpaceXform needs to premultiply.
>
> The bitsPerComponent is potentially useful for a client; Android (in
> SkAndroidCodec) uses it to determine the SkColorType. Rather than
> exposing bitsPerComponent, use it to make the same decision that Android
> would have made - 16 bits per component means to set the info to F16. Add
> a test that computeOutputColorType behaves as expected.
>
> Switch conversionSupported to use an SkColorType, which is enough info.
>
> Replace the SkEncodedInfo::Alpha field on SkCodec::FrameInfo with an
> SkAlphaType.
>
> SkCodec still needs an SkEncodedInfo, so move its header (which is
> already not SK_API) to include/private.
>
> Change-Id: Ie2cf11339bf999ebfd4390c0f448f7edd6feabda
> Reviewed-on: https://skia-review.googlesource.com/79260
> Reviewed-by: Mike Reed <reed@google.com>
> Reviewed-by: Mike Klein <mtklein@chromium.org>
> Commit-Queue: Leon Scroggins <scroggo@google.com>
TBR=mtklein@chromium.org,scroggo@google.com,reed@google.com
Change-Id: I0c5dd1461e1b70d1e55349a8e7ee6b029c3f556e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:7353, skia:6839
Reviewed-on: https://skia-review.googlesource.com/80660
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Bug: skia:7353
Bug: skia:6839
This contains information that is not necessary for clients to know. The
Color enum tells the number of components in the input, but this is only
interesting internally (to the SkSwizzler).
Similarly, the Alpha enum differs from SkAlphaType in that it has
kBinary instead of kPremul. This is useful information only internally
for determining whether the SkColorSpaceXform needs to premultiply.
The bitsPerComponent is potentially useful for a client; Android (in
SkAndroidCodec) uses it to determine the SkColorType. Rather than
exposing bitsPerComponent, use it to make the same decision that Android
would have made - 16 bits per component means to set the info to F16. Add
a test that computeOutputColorType behaves as expected.
Switch conversionSupported to use an SkColorType, which is enough info.
Replace the SkEncodedInfo::Alpha field on SkCodec::FrameInfo with an
SkAlphaType.
SkCodec still needs an SkEncodedInfo, so move its header (which is
already not SK_API) to include/private.
Change-Id: Ie2cf11339bf999ebfd4390c0f448f7edd6feabda
Reviewed-on: https://skia-review.googlesource.com/79260
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Fixes build errors with latest ANGLE, should allow roll to land.
Bug: skia:
Change-Id: I44c7b2ed8bf3a8dbfa70a16aed51c45f2c7d5b71
Reviewed-on: https://skia-review.googlesource.com/70461
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit 5411a60e0d.
Reason for revert: ASAN and Coverage failing: https://chromium-swarm.appspot.com/task?id=394978f3b7d44610
Flutter_Android failing.
Original change's description:
> Add an Option for orientation on JPEG encodes
>
> Move Origin to its own header so that SkPixmap and SkJpegEncoder need
> not depend on SkCodec.
>
> Add libexif, which is already used by Android, and use it to write the
> orientation. Write a makefile based on the Android.bp in Android, minus
> warnings. (libexif has an LGPL license.)
>
> Add a test that verifies all the orientations work.
>
> Optionally enable writing the orientation (and therefore including
> libexif). Chromium does not currently need it, and Android does not
> expose an API that would allow using it. Disable on Windows, where we
> still have build errors to fix.
>
> Bug: skia:7138
> Change-Id: Iaeff44c36aebe0e639666979dc00e1b7594bbeb1
> Reviewed-on: https://skia-review.googlesource.com/60721
> Commit-Queue: Leon Scroggins <scroggo@google.com>
> Reviewed-by: Mike Klein <mtklein@chromium.org>
> Reviewed-by: Mike Reed <reed@google.com>
TBR=mtklein@chromium.org,mtklein@google.com,scroggo@google.com,reed@google.com
Change-Id: I05b7ae8d1c5bbd1de1642d9ef024943500256273
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:7138
Reviewed-on: https://skia-review.googlesource.com/61620
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Commit-Queue: Ben Wagner <benjaminwagner@google.com>
Move Origin to its own header so that SkPixmap and SkJpegEncoder need
not depend on SkCodec.
Add libexif, which is already used by Android, and use it to write the
orientation. Write a makefile based on the Android.bp in Android, minus
warnings. (libexif has an LGPL license.)
Add a test that verifies all the orientations work.
Optionally enable writing the orientation (and therefore including
libexif). Chromium does not currently need it, and Android does not
expose an API that would allow using it. Disable on Windows, where we
still have build errors to fix.
Bug: skia:7138
Change-Id: Iaeff44c36aebe0e639666979dc00e1b7594bbeb1
Reviewed-on: https://skia-review.googlesource.com/60721
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
Add new application, called GPU-CTS (GPU Compatibility Test Suite),
which executes skia gms against OpenGL and Vulkan backends. Makes use
of googletest library for consistancy with Android CTS programs.
Add googletest to DEPS
gm_knowledge.h header as a stub for future work on validating gm output.
gm_runner can be re-used in other programs. Talks to Skia and GM with a
simple API.
gpuctx executable wraps gm_runner and googletest together.
Change-Id: Ie7350b22164fa73e44121c39b0f36da4038a700b
Reviewed-on: https://skia-review.googlesource.com/56601
Reviewed-by: Hal Canary <halcanary@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
Apparently 1.6.34 has been released too, but I can't find it in Git, and
1.6.33 is the one with that patch we're really interested in, right?
Let's also just #include the prebuilt pnglibconf.h to make it clear that
it's unchanged from the original?
Change-Id: Ia415486f30c7aff1575f96add8edce855eef9207
Reviewed-on: https://skia-review.googlesource.com/54040
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
After updating the transparency index code, the reader parameter to
SkGIFFrameContext's ctor is no longer needed. This patch removes it.
BUG=skia:7069
Change-Id: If129f825639e8d43d73794adca2de09785f56a3c
Reviewed-on: https://skia-review.googlesource.com/52602
Commit-Queue: Chris Blume <cblume@chromium.org>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Other browsers (including old Chrome) treat invalid palette indices as
transparent for gifs. And there are gifs in the wild which rely on this.
As an example, if the palette only has 64 entries (0-63) then index 64
is treated as transparent.
BUG=skia:7069
Change-Id: I15e8919a953387506c9ac5945c3ae6a2b90189ab
Reviewed-on: https://skia-review.googlesource.com/51100
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Chris Blume <cblume@google.com>
The incorrect output file name meant that the update_build_version.py script
was being run on every build, resulting in unnecessary work.
Bug: skia:
Change-Id: I5da933fb9b8fdf0bc898d0e90eaae0a542cfb3b3
Reviewed-on: https://skia-review.googlesource.com/50302
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
I'd have done this as two steps, but we didn't have a pure copy of
libpng to start with. The patches we did have, though, have been
upstreamed and are now unneeded.
Change-Id: I884b9bc47afe5000f5a521f66a3bb95c0411b39a
Reviewed-on: https://skia-review.googlesource.com/48620
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
It turns out that Skia's gn 'system' and 'third_party' templates differ
in the way public defines are declared. This also updates the build to
add libdl when building SkOSLibrary_posix.cpp, since that uses dlsym.
The current build depends on icu bringing in this dependency.
BUG=skia:7008
Change-Id: Ia710a335e1da9580f85f133a5a171f640b36ee75
Reviewed-on: https://skia-review.googlesource.com/41745
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Yuqian Li <liyuqian@google.com>
Change-Id: Ib8f4d6c41356cf0fe2e14b7bff7713d107eaa01f
Reviewed-on: https://skia-review.googlesource.com/40687
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Speculative fix for a memory regression seen in Chromium. Chromium
previously used a WTF::Vector, which has a growth factor of 1.5, as does
SkTArray. Depending on the implementation of std::vector, this may slow
the allocation of memory.
Bug: 758946
Change-Id: I323390027467e32a6c66667c927fae0aba292446
Reviewed-on: https://skia-review.googlesource.com/40777
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
