This limit matches the limit used by Chromium. I am not aware of any
real world BMPs that are larger than this (or even close to it), but
there are some invalid BMPs that are larger than this, leading to
crashes when we try to read a row.
BUG:34778578
BUG=skia:3617
Change-Id: I0f662e8d0d7bc0b084e86d0c9288b831e1b296d7
Reviewed-on: https://skia-review.googlesource.com/8966
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
An RLE bmp reports how many bytes it should contain. This number may be
incorrect, or it may be a very large number. Previously, we buffered
all bytes in a single allocation. Instead, use a fixed size buffer and
only read what fits into the buffer. We already have code to refill the
buffer if there is more data, so rely on that to keep reading.
Choose an arbitrary size for the buffer. It is larger than the maximum
possible number of bytes we need to read at once.
Add a test with a test image that reports a very large number for
the number of bytes it should contain. With the old method, we would
allocate 4 gigs of memory to decode this image, which is unnecessary
and may result in OOM.
BUG=b/33251605
Change-Id: I6d66eace626002725f62237617140cab99ce42f3
Reviewed-on: https://skia-review.googlesource.com/7028
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
If a frame does not have a valid transparent index and it covers the
prior frame, it does not really depend on that frame. Instead, it
depends on the frame that the prior frame depends on.
Determine this once we have parsed the local color map (if any), so a
transparent index out of range of the color map is not considered
valid.
Share code that determines whether a frame has a transparent pixel.
Add a test that we compute the dependencies correctly. randPixelsAnim.gif
has 13 frames. After the first, the frames cover all combinations of
- Whether the prior frame was keep, restoreBG or restoreToPrevious
- Whether the new frame covers the prior frame
- Whether the new frame has a transparent pixel
(It only does so when using a global color table. It may make sense to
expand the test to also cover using local color tables.)
The test caught a bug where we incorrectly reused an existing
SkColorTable for a different frame. Fix that bug by keeping track of
the transparent index associated with the current SkColorTable.
Change-Id: I3cf6be7f612990fa7a00d9e74d116d31bd227526
Reviewed-on: https://skia-review.googlesource.com/6402
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Recent changes (crrev.com/2045293002) made it so that a GIF may not
support index 8. In that case, make SkAndroidCodec not suggest index 8.
Add a test and a new test file. randPixelsOffset.gif is the same as
randPixels.gif, except its frame is offset. Since it does not have a
transparent index, we have to decode to kN32.
Change-Id: I1c09ab9094083de3dfc436632b3c26dbde1dccbd
Reviewed-on: https://skia-review.googlesource.com/6196
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
In SkBmpCodec, if the header size does not match a known header,
stop trying to create an SkCodec. We do not know of any BMPs with
arbitrarily sized headers, so this should not cause any real
regressions.
In addition, this fixes a bug where we attempt to read too much data
from a file. Since we attempt to read the header size in one read,
and a size reported by the "BMP" may be larger than SSIZE_MAX, this
will crash when reading from a file.
Add a test.
BUG:b/33651913
Change-Id: I0f3292db3124dc5ac5cbdbc07196bda130a49ba7
Reviewed-on: https://skia-review.googlesource.com/6150
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@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>
Add a test
BUG=skia:3534
BUG=b/33300701
Change-Id: Ifb3a824a36998c5e626c4ad58466845f49d18ebf
Reviewed-on: https://skia-review.googlesource.com/5568
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Add a new accessor to retrieve the repetition count.
Remove constants (and corresponding copyright) in SkCodecAnimation.
These may make sense for the calling code, but are not needed here.
kRepetitionCountInfinite corresponds to Blink's kAnimationLoopInfinite.
Move cLoopCountNotSeen to private. It is used to determine whether we
still need to parse. Add a new enum to the parse query - only parse
enough to determine the repetition count.
Unlike Chromium, SkGifCodec does not account for deleting the reader
(which SkGifCodec does not do) or failed decodes.
Add a test.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2447863002
Review-Url: https://codereview.chromium.org/2447863002
While investigating skbug.com/5883 I noticed that we use the color
table for the current frame even while recursively decoding frames that
the current frame depends on.
This CL updates fCurrColorTable, fCurrColorTableIsReal and fSwizzler
before decoding prior frames, and then sets them back afterwards.
Move telling the client about the color table into prepareToDecode,
since the other callers do not need to do so. (That is only necessary
for decoding to index 8, which is unsupported for frames with
dependencies.)
Add a test that exposes the bug. colorTables.gif has a local color
table in its second frame that does not match the global table used by
the first frame.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4208
Change-Id: Id2dc9e3283adfd92801d2f38726afa74574b1955
Reviewed-on: https://skia-review.googlesource.com/4208
Reviewed-by: Joost Ouwerling <joostouwerling@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
BUG:660838
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4200
Change-Id: Ib57eb3705d6fe638e3a9cb56788937fc7e282847
Reviewed-on: https://skia-review.googlesource.com/4200
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
The refactoring breaks off A2B0 tag support into a separate
subclass of SkColorSpace_Base, while keeping the current
(besides CLUT) functionality in a XYZTRC subclass.
ICC profile loading is now aware of this and creates the A2B0
subclass when SkColorSpace::NewICC() is called on a profile
in need of the A2B0 functionality.
The LabPCSDemo GM loads a .icc profile containing a LAB PCS and
then runs a Lab->XYZ conversion on an image using it so we can
display it and test out the A2B0 SkColorSpace functionality,
sans a/b/m-curves, as well as the Lab->XYZ conversion code.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2389983002
Review-Url: https://codereview.chromium.org/2389983002
Original Commit Message:
"""
Avoid integer overflow in SkIcoCodec
Definitely good to avoid overflow here.
FWIW, this looks to be harmless for Android's current use.
They will just fail later on when trying to allocate the
bitmap.
BUG=skia:5857
"""
With the new test, ASAN also caught an integer overflow
bug in SkImageInfo. Fix this as well.
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-ASAN;master.client.skia.android:Test-Android-Clang-AndroidOne-CPU-MT6582-arm-Debug-GN_Android
BUG=skia:5857
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3568
Change-Id: I0d777a547850474ea6cea87e36efa05434e33635
Reviewed-on: https://skia-review.googlesource.com/3568
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Definitely good to avoid overflow here.
FWIW, this looks to be harmless for Android's current use.
They will just fail later on when trying to allocate the
bitmap.
BUG=skia:5857
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3527
Change-Id: Ia1fb7d864d21ecdb127a1dd1a72cab8375cb43fb
Reviewed-on: https://skia-review.googlesource.com/3527
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
The hintgasp font was added specifically for the typefacerendering gm.
However, this gm didn't actually use the font, so now use it. In
addition this adds embedded bitmap strikes to the hintgasp font and the
gm is updated to test these as well.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2140863002
NOTREECHECKS=true
Test only change, does not affect users.
Review-Url: https://codereview.chromium.org/2140863002
(1) Draw triangles onto a D50 color gamut so they are
actually in the correct place.
(2) Add options to display canonical sRGB and Adobe RGB
gamuts.
(3) Label the R, G, and B points of the color gamut.
(4) Decode and reencode the input image without color
correction, so we can compare to the corrected version.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2017153002
Review-Url: https://codereview.chromium.org/2017153002
This will allow me to test and visualize some assumptions
on parsing and applying color profiles. Also, it should
help me find and fix bugs.
This is certainly not an optimized implementation, and, as
far as I know, it doesn't take any shortcuts to improve
performance. We'll probably want to do both of these
once we know where it fits in the pipeline.
Right now this test is only run on an arbitrary set of ~100
images from the top 10k skps. I'll continue to add more
"interesting" images and probably tweak the code as
necessary.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1995233003
Review-Url: https://codereview.chromium.org/1995233003
This reverts commit 554784cd85 and
1956b4ae1c
Reason for revert - ASAN failures, e.g. from https://uberchromegw.corp.google.com/i/client.skia/builders/Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Debug-MSAN/builds/2233/steps/perf_skia%20on%20Ubuntu/logs/stdio :
Uninitialized value was created by a heap allocation
0 0x7f69aa96f799 in operator new[](unsigned long) /b/work/skia/third_party/externals/llvm/out/../projects/compiler-rt/lib/msan/msan_new_delete.cc:37
1 0x7f69aaa315c1 in SkAutoTArray<unsigned int>::reset(int) /b/work/skia/out/Build-Ubuntu-GCC-x86_64-Debug-MSAN/Debug/../../../include/private/../private/SkTemplates.h:137:22
2 0x7f69aaa34ee9 in LinearSrcOverBench<SrcOverVSkOptsSSE41>::LinearSrcOverBench(char const*) /b/work/skia/out/Build-Ubuntu-GCC-x86_64-Debug-MSAN/Debug/../../../bench/SkBlend_optsBench.cpp:108:9
3 0x7f69aaa30cf2 in $_24::operator()(void*) const /b/work/skia/out/Build-Ubuntu-GCC-x86_64-Debug-MSAN/Debug/../../../bench/SkBlend_optsBench.cpp:167:1
4 0x7f69aaa30c87 in $_24::__invoke(void*) /b/work/skia/out/Build-Ubuntu-GCC-x86_64-Debug-MSAN/Debug/../../../bench/SkBlend_optsBench.cpp:167:1
5 0x7f69aaa68856 in BenchmarkStream::rawNext() /b/work/skia/out/Build-Ubuntu-GCC-x86_64-Debug-MSAN/Debug/../../../bench/nanobench.cpp:653:32
6 0x7f69aaa61467 in BenchmarkStream::next() /b/work/skia/out/Build-Ubuntu-GCC-x86_64-Debug-MSAN/Debug/../../../bench/nanobench.cpp:642:25
7 0x7f69aaa5b703 in nanobench_main() /b/work/skia/out/Build-Ubuntu-GCC-x86_64-Debug-MSAN/Debug/../../../bench/nanobench.cpp:1119:27
8 0x7f69aaa5e10d in main /b/work/skia/out/Build-Ubuntu-GCC-x86_64-Debug-MSAN/Debug/../../../bench/nanobench.cpp:1290:12
9 0x7f69a8c95ec4 in __libc_start_main /build/buildd/eglibc-2.19/csu/libc-start.c:287
TBR=herb@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1969803002
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review-Url: https://codereview.chromium.org/1969803002
Add this flag to SampleApp, and it will run with the specified restricted sequence
--sequence /skia/trunk/resources/nov-talk-sequence.txt
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1410243009
Benefits:
- This mimics other decoding APIs (including the ones SkCodec relies
on, e.g. a png_struct, which can be used to decode an entire image or
one line at a time).
- It allows a client to ask us to do what we can do efficiently - i.e.
start from encoded data and either decode the whole thing or scanlines.
- It removes the duplicate methods which appeared in both SkCodec and
SkScanlineDecoder (some of which, e.g. in SkJpegScanlineDecoder, just
call fCodec->sameMethod()).
- It simplifies moving more checks into the base class (e.g. the
examples in skbug.com/4284).
BUG=skia:4175
BUG=skia:4284
=====================================================================
SkScanlineDecoder.h/.cpp:
Removed.
SkCodec.h/.cpp:
Add methods, enums, and variables which were previously in
SkScanlineDecoder.
Default fCurrScanline to -1, as a sentinel that start has not been
called.
General changes:
Convert SkScanlineDecoders to SkCodecs.
General changes in SkCodec subclasses:
Merge SkScanlineDecoder implementation into SkCodec. Most (all?) owned
an SkCodec, so they now call this-> instead of fCodec->.
SkBmpCodec.h/.cpp:
Replace the unused rowOrder method with an override for
onGetScanlineOrder.
Make getDstRow const, since it is called by onGetY, which is const.
SkCodec_libpng.h/.cpp:
Make SkPngCodec an abstract class, with two subclasses which handle
scanline decoding separately (they share code for decoding the entire
image). Reimplement onReallyHasAlpha so that it can return the most
recent result (e.g. after a scanline decode which only decoded part
of the image) or a better answer (e.g. if the whole image is known to
be opaque).
Compute fNumberPasses early, so we know which subclass to instantiate.
Make SkPngInterlaceScanlineDecoder use the base class' fCurrScanline
rather than a separate variable.
CodexTest.cpp:
Add tests for the state changes in SkCodec (need to call start before
decoding scanlines; calling getPixels means that start will need to
be called again before decoding more scanlines).
Add a test which decodes in stripes, currently only used for an
interlaced PNG.
TODO: Add tests for onReallyHasAlpha.
Review URL: https://codereview.chromium.org/1365313002
Chromium's test suite contains an RLE image that reports a certain
file size in the header, but then contains additional encoded data.
Our bmp decoder would only decode half of the image, before stopping.
With this fix, we check for additional data before returning
kIncompleteInput.
If this lands, I will upload the test image to the bots.
Also adding an invalid image test to CodexTest.
BUG=skia:
Review URL: https://codereview.chromium.org/1273853004
We are also changing the wbmp to use SkSwizzler. This
will allow us to take advantage of the sampling routines
that are being implemented in SkSwizzler.
The image in this upload came from:
https://commons.wikimedia.org/wiki/File:Android_robot.png
It is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license.
BUG=skia:
Review URL: https://codereview.chromium.org/1254483004
Reason for revert:
Compilation failures:
../../../../../samplecode/SampleLighting.cpp:13:18: fatal error: SkGr.h: No such file or directory
Original issue's description:
> Add normal map sample
>
> This adds an example of an SkShader that does normal
> mapping. It has a single directional light and an
> ambient light.
>
> Committed: https://skia.googlesource.com/skia/+/8e0da72ba890de395c9946ec6639c9e1e7b16027TBR=reed@google.com,bsalomon@google.com,jvanverth@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1230603002
This adds an example of an SkShader that does normal
mapping. It has a single directional light and an
ambient light.
Review URL: https://codereview.chromium.org/1212813009
DEPS:
Update to pull v0.4.3 of libwebp from upstream
gyp/libwebp.gyp:
Add new files, as referenced by the gyp file used by Chromium.
resource/tests:
Add regression tests for particular images.
BUG=skia:3442
BUG=skia:3315
BUG=skia:3429
Review URL: https://codereview.chromium.org/1178013008
FreeType automatically selects the 'most Unicode' cmap available,
otherwise the default cmap is NULL. When this happens the fallback
should include the 3,0 symbol cmap, as is outlined in the Apple
TrueType documentation. This cmap should effectively be a Unicode
mapping, but exclusively in the private use area.
BUG=skia:1873,chromium:489452
Review URL: https://codereview.chromium.org/1163833003
This test font contains
☓ U+2613 SALTIRE
⬛ U+2B1B BLACK LARGE SQUARE
⬜ U+2B1C WHITE LARGE SQUARE
All at full EM size (with standard amount above and below the
baseline).
Review URL: https://codereview.chromium.org/1134153002
Reason for revert:
Appears to be breaking Linux ARM bots:
FAILED:
/usr/local/google/home/mosaic-role/slave/repo_clients/chromium_tot/chromium/src/../../prebuilt/toolchain/armv7a/bin/armv7a-cros-linux-gnueabi-g++
... -o obj/third_party/skia/src/ports/skia_library.SkFontHost_FreeType.o
../../third_party/skia/src/ports/SkFontHost_FreeType.cpp:37:31: fatal error:
freetype/ftmm.h: No such file or directory
#include FT_MULTIPLE_MASTERS_H
^
compilation terminated.
Original issue's description:
> Font variations.
>
> Multiple Master and TrueType fonts support variation axes.
> This implements back-end support for axes on platforms which
> support it.
>
> Committed: https://skia.googlesource.com/skia/+/05773ed30920c0214d1433c07cf6360a05476c97
>
> Committed: https://skia.googlesource.com/skia/+/3489ee0f4fa34f124f9de090d12bdc2107d52aa9TBR=reed@google.com,mtklein@google.com,djsollen@google.com,halcanary@google.com,bungeman@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1139123008
Multiple Master and TrueType fonts support variation axes.
This implements back-end support for axes on platforms which
support it.
Review URL: https://codereview.chromium.org/1027373002
The entire text content of the 'font' element is currently used as the
file name. This wasn't an issue in earlier versions, as the 'file'
element was dedicated to only containing the file name. The new 'font'
element also contains a number of attributes and potentially other tags.
This means that a 'font' element can become quite long, making it
desireable to be able to split it across multiple lines.
However, splitting the 'font' element across multiple lines is currently
difficult and awkward as any whitespace outside of tags will be
considered part of the file name. This change means that any leading or
trailing whitespace will not be considered part of the file name.
This only applies to v21 and later files, so while this restricts font
file names from beginning and ending with whitespace, it is unlikely to
break any users in practice. It is probably also undesireable to have
font files with names that begin or end with whitespace in any event.
Review URL: https://codereview.chromium.org/1125413003
This font contains two glyphs, one for 'a' and one for 'A'. The em size
is 128, and the 'a' fits in this. The big 'A', however, is ~3000 in
in each direction.
Review URL: https://codereview.chromium.org/1016153002
The language was being set to garbage, now set to part of the file name.
Add a test to ensure we continue to parse fallback directories correctly.
BUG=chromium:422180
Review URL: https://codereview.chromium.org/912053003
We previously saw crashes decoding bad ICO files. Add tests for
known bad files.
While testing, I learned that one of them still crashes. Check for
large offset and size separately to fix the crash.
BUG=skia:2878
Review URL: https://codereview.chromium.org/712123002
On android trybots, the files in a subdirectory weren't being
loaded onto the device. Consequently, the ImageDecoderOptions
test was not testing anything. I had to relax that unit test
to reflect the existing behavior of our libjpeg decoder on
Android.
R=djsollen@google.com
Review URL: https://codereview.chromium.org/264583007
git-svn-id: http://skia.googlecode.com/svn/trunk@14682 2bbb7eff-a529-9590-31e7-b0007b416f81
