These cuts reduce the number of files by 2/3 and the size by 1/3
There's not too much more that could be trimmed - now the size
is dominated by the specially compiled LLVM/Clang binaries
Bug: skia:7186
Change-Id: Ie88fb6f2277eafbefac0f676daaca809dcb53f62
Reviewed-on: https://skia-review.googlesource.com/107061
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
I will use this in skcms-Win bots.
Change-Id: Id2e253a73e562181649f17908e5d587cc0d098d6
Reviewed-on: https://skia-review.googlesource.com/106973
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Bug: skia:
Change-Id: I55bb57a7f199d0f57531523f1fedfec2bf49502c
Reviewed-on: https://skia-review.googlesource.com/106802
Commit-Queue: Eric Boren <borenet@google.com>
Reviewed-by: Stephan Altmueller <stephana@google.com>
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>
'windk' is no longer a thing. There are two separate variables to point
at your compiler (win_vc), and SDK (win_sdk).
'msvc' is no longer a thing, either. By default, we look for 2017 and
then 2015 (in the default locations). If neither is located, use an
assert to let users know they should set win_vc. Then, detect if win_vc
points at a 2017 or 2015 installation, and configure it automatically.
Because the toolchain is now 2017, update the GN files to handle building
x86 in that configuration. In fact, we only support x86 builds (with 2017
or 2015) using the toolchain assets. Keep a 2015 toolchain around as a
new asset, so we can add bot coverage.
Docs-Preview: https://skia.org/?cl=81841
Bug: skia:
Change-Id: I8c68a6f949e54c0e798a219450bbb9406f8dc6ac
Reviewed-on: https://skia-review.googlesource.com/81841
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Brian Osman <brianosman@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>
The old code made the wrong assumptions about premultiplication.
There are three relevant steps here for decoding a webp frame:
1 tell libwebp to decode
2 colorXform the result (sometimes)
3 blend with the prior frame (sometimes)
Rearrange the code to premultiply at the blend step, in a linear space.
If the client wants unpremul, the blend step will unpremul after.
If there is no blending, the colorXform (if any) will premultiply.
If only step 1 is necessary, let libwebp premultiply.
This fixes an animated image that has an opaque frame 0 followed by a
frame with alpha that blends with it.
Add the test image that failed (https://mathiasbynens.be/demo/animated-webp)
The prior fix is in 42bae8faa4. It did
not properly handle the colorXform when there was no blending step.
Change-Id: I2b9d265ba162eaf7e55a106c8f79341826cee0d3
Reviewed-on: https://skia-review.googlesource.com/72281
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
This reverts commit 42bae8faa4.
Reason for revert: Breaking GMs. A more extensive fix is needed.
Original change's description:
> Fix webp bug compositing alpha frames on opaque
>
> select_xform_alpha is used to determine how the color transform should
> handle alpha values. In a similar way, we're using it here to determine
> whether to premultiply pixels before blending them. In this case, the
> source is unpremul, so we should be premultiplying them, but since we
> are compositing on an opaque frame, the dst must be opaque and
> select_xform_alpha returns kOpaque. As a result, we do not premultiply
> (and even hint to the transform that the pixels are opaque). Since this
> all applies to the pre-blended pixels, we should not care that the dst
> is opaque. So drop the call to select_xform_alpha and just use the alpha
> type of the source. This matches the comment on the lines above.
>
> Add the test image that failed (https://mathiasbynens.be/demo/animated-webp)
>
> Change-Id: Ibd13c1f067bdf369ce1c882d4f6057aadccfa313
> Reviewed-on: https://skia-review.googlesource.com/71560
> Commit-Queue: Leon Scroggins <scroggo@google.com>
> Reviewed-by: Mike Klein <mtklein@chromium.org>
TBR=mtklein@chromium.org,scroggo@google.com
Change-Id: I6f535ff9b773a93e02a0358b830291594a6e738c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/71720
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
select_xform_alpha is used to determine how the color transform should
handle alpha values. In a similar way, we're using it here to determine
whether to premultiply pixels before blending them. In this case, the
source is unpremul, so we should be premultiplying them, but since we
are compositing on an opaque frame, the dst must be opaque and
select_xform_alpha returns kOpaque. As a result, we do not premultiply
(and even hint to the transform that the pixels are opaque). Since this
all applies to the pre-blended pixels, we should not care that the dst
is opaque. So drop the call to select_xform_alpha and just use the alpha
type of the source. This matches the comment on the lines above.
Add the test image that failed (https://mathiasbynens.be/demo/animated-webp)
Change-Id: Ibd13c1f067bdf369ce1c882d4f6057aadccfa313
Reviewed-on: https://skia-review.googlesource.com/71560
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Add --depth 1 to the git clone commands to speed up the creation,
since we don't need all of the history ever to build.
Bug: skia:7080
Change-Id: Idcde5657e2097c2dbc259ab29b24d596b5623364
Reviewed-on: https://skia-review.googlesource.com/53481
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Bug: b/65290323
If a webp file is truncated such that no rows can be decoded,
WebPIDecGetRGB does not initialize its "last_y" parameter. We use
rowsDecoded (passed as last_y) to determine which remaining rows to
fill.
Check the return value of WebPIDecGetRGB. If it fails (returns null),
or rowsDecoded is <= 0 (matching Chromium's check), return
kInvalidInput, since there is nothing to draw.
Note that this is a change in behavior for Android. Previously we
would decode an empty webp to just a transparent/black rectangle,
whereas now we simply fail. I think this is a change for the better.
Add a test which truncates a file to have 0 rows available and attempts
to decode it. msan verifies that we no longer depend on the
uninitialized value.
Stop attempting to test decoding subsets from an incomplete webp (in
CodecTest.cpp). Unless we have decoded the portion covered by the
subset, this will fail.
Remove test images inc0.webp (from both dm/ and colorspace/) and
inc1.webp. These just decode to transparent rectangles. Replace them
with inc2.webp and inc3.webp, which decode part of the image and then
have to fill with transparent.
Change-Id: I64d40be91c574b45963f9a43d8dd8f4929dd2939
Reviewed-on: https://skia-review.googlesource.com/50303
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: James Zern <jzern@google.com>
Fix core.gni to use not use Assembler for none cpu.
Right now, there are no outputs because we aren't compiling
dm or nanobench. However, this still compiles the skia
library and creates two executables, so it's a good canary
for a real WASM build.
Additional note: the two executables in question don't draw
anything to the screen via GL, which is still not possible with
Skia+WASM.
Bug: skia:
Change-Id: I0d767467e94e40d01070e34223dd90e96f1c96f2
Reviewed-on: https://skia-review.googlesource.com/49540
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Eric Boren <borenet@google.com>
Automatic commit by the RecreateSKPs bot.
TBR=update-skps@skia.org
NO_MERGE_BUILDS
Change-Id: I73dd583f3891dc49402068670d0fb0dabafe0e4d
Reviewed-on: https://skia-review.googlesource.com/47701
Reviewed-by: Ravi Mistry <rmistry@google.com>
Commit-Queue: Ravi Mistry <rmistry@google.com>
Disable some new warning flags to get us building.
Change-Id: I10299d667b06fb61d03e52329883c634bd42f45c
Reviewed-on: https://skia-review.googlesource.com/44341
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Context is in the below bug
Bug: skia:6918
Change-Id: Ic9048311092bd7e73dd6ee182e79abea79baa07a
Reviewed-on: https://skia-review.googlesource.com/30586
Commit-Queue: Ravi Mistry <rmistry@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
Image origin: https://github.com/flutter/flutter/issues/11521
Bug: skia:
Change-Id: I5af8b155a4979c83d3dd9c0bdd15e0052c6d1f88
Reviewed-on: https://skia-review.googlesource.com/32000
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Eric Boren <borenet@google.com>
Bug: skia:6881
Change-Id: I8c1e4be16f4a79e9aa6fb663337476d0c0fe8c1c
Reviewed-on: https://skia-review.googlesource.com/31024
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Ben Wagner <benjaminwagner@google.com>
Bug: skia:2679
Change-Id: I7abffae32102a69271b23834a121c51426813e27
Reviewed-on: https://skia-review.googlesource.com/28785
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
