Better imitate the original Android bug. Create a stream with
multiple images in it, and verify that it successfully decodes after
decoding once.
This exposes a bug in SkPngCodec, which did not work for interlaced
images.
Test more formats that also happen to succeed: ICO, BMP, and WBMP
This explicitly does *not* attempt to fix sampled or subset
decodes, which already stopped early when decoding as an
optimization.
Change-Id: Ib0b8918f14ba3fb0fa31e9c71c8100dcbeeb465f
Reviewed-on: https://skia-review.googlesource.com/14104
Reviewed-by: Matt Sarett <msarett@google.com>
This reverts commit df2bf21364.
Reason for revert: Maybe AndroidOne timing out
Original change's description:
> Split up opLists (take 2)
>
> Reland of: https://skia-review.googlesource.com/c/11581/ (Split up opLists)
>
> https://skia-review.googlesource.com/c/13860/ (Make InstancedRendering more opList-splitting friendly) has landed so this should be good for another attempt.
>
> Change-Id: Icc9998196587510328e0a9ca1b2ce42013a86c6c
> Reviewed-on: https://skia-review.googlesource.com/13802
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Robert Phillips <robertphillips@google.com>
>
TBR=bsalomon@google.com,robertphillips@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I744f2a3145b294e5911862bb39d57ca33a1b9a5a
Reviewed-on: https://skia-review.googlesource.com/14184
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
If process_data is unable to read (and therefore process) as many bytes
as it expects, process the bytes read before returning false.
Fixes differences in Gold.
Add a test that verifies that it is okay to call png_process_data with
0 bytes. (We could special case 0, but libpng already checks for 0.)
Change-Id: Id500b9305ee3bb6a1a7e8fc70d4e723cb4742b55
Reviewed-on: https://skia-review.googlesource.com/14144
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
(Originally uploaded as 13900.)
Previously, SkPngCodec assumed that the stream only contained one
image, which ended at the end of the stream. It read the stream in
arbitrarily-sized chunks, and then passed that data to libpng for
processing.
If a stream contains more than one image, this may result in reading
beyond the end of the image, making future reads read the wrong data.
Now, SkPngCodec starts by reading 8 bytes at a time. After the
signature, 8 bytes is enough to know which chunk is next and how many
bytes are in the chunk.
When decoding the size, we stop when we reach IDAT, and when decoding
the image, we stop when we reach IEND.
This manual parsing is necessary to support APNG, which is planned in
the future. It also allows us to remove the SK_GOOGLE3_PNG_HACK, which
was a workaround for reading more than necessary at the beginning of
the image.
Add a test that simulates the issue, by decoding a special stream that
reports an error if the codec attempts to read beyond the end.
Temporarily disable the partial decoding tests for png. A larger change
will be necessary to get those working again, and no clients are
currently relying on incrementally decoding PNGs (i.e. decode part of
an image, then decode further with more data).
Include a workaround for older versions of libpng (e.g. 1.2 in
Google3). In older versions, if the row callback is null when the
IDAT header is processed, reading the image will fail. When we see the
IDAT, we save the length and process a recreated IDAT header later,
after the row callback has been set.
Bug: skia:5368
Bug:b/34073812
Test: Existing tests, plus a new test in dm.
Change-Id: I293a4ddc013b82669a8b735062228b26d0bce933
Reviewed-on: https://skia-review.googlesource.com/13984
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
My main interest is getting rid of weird code, but it's also faster.
The new bench drops from 667 to 412.
Change-Id: Ibf889601284cf925780320c828394f79937dc705
Reviewed-on: https://skia-review.googlesource.com/14035
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This reverts commit 02242e82e4.
Reason for revert: Maybe breaking Chrome DEPS roll
Original change's description:
> Rm makeRenderTargetContext in favor of deferred version (take 2)
>
> This is a reland of: https://skia-review.googlesource.com/c/13001/ (Rm makeRenderTargetContext in favor of deferred version)
>
> Change-Id: Ife77b012d09c46895884a168fc5045bd92a4b919
> Reviewed-on: https://skia-review.googlesource.com/13196
> Reviewed-by: Greg Daniel <egdaniel@google.com>
> Commit-Queue: Robert Phillips <robertphillips@google.com>
>
TBR=egdaniel@google.com,bsalomon@google.com,robertphillips@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I2607116ed743f5d313da4a7b7f056776ed907702
Reviewed-on: https://skia-review.googlesource.com/14024
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This reverts commit 2c65d51612.
Reason for revert: Causing failures in Google3 (https://test.corp.google.com/ui#cl=153703311&flags=CAMQAg==&id=OCL:153703311:BASE:153703364:1492695824938:4db2240d&t=//chrome/skia/dm_wrapper:dm_wrapper) and differences in Gold. This change was not intended to change the output.
Original change's description:
> Make SkPngCodec only read as much of the stream as necessary
>
> Previously, SkPngCodec assumed that the stream only contained one
> image, which ended at the end of the stream. It read the stream in
> arbitrarily-sized chunks, and then passed that data to libpng for
> processing.
>
> If a stream contains more than one image, this may result in reading
> beyond the end of the image, making future reads read the wrong data.
>
> Now, SkPngCodec starts by reading 8 bytes at a time. After the
> signature, 8 bytes is enough to know which chunk is next and how many
> bytes are in the chunk.
>
> When decoding the size, we stop when we reach IDAT, and when decoding
> the image, we stop when we reach IEND.
>
> This manual parsing is necessary to support APNG, which is planned in
> the future. It also allows us to remove the SK_GOOGLE3_PNG_HACK, which
> was a workaround for reading more than necessary at the beginning of
> the image.
>
> Add a test that simulates the issue, by decoding a special stream that
> reports an error if the codec attempts to read beyond the end.
>
> Temporarily disable the partial decoding tests for png. A larger change
> will be necessary to get those working again, and no clients are
> currently relying on incrementally decoding PNGs (i.e. decode part of
> an image, then decode further with more data).
>
> Bug: skia:5368
> BUG:34073812
>
> Change-Id: If832f7b20565411226fb5be3c305a4d16bf9269d
> Reviewed-on: https://skia-review.googlesource.com/13900
> Commit-Queue: Leon Scroggins <scroggo@google.com>
> Reviewed-by: Matt Sarett <msarett@google.com>
>
TBR=msarett@google.com,scroggo@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I2f82e9960dda7bf5c646774df84320dadb7b930e
Reviewed-on: https://skia-review.googlesource.com/13971
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This is the other half of https://skia-review.googlesource.com/c/7874/,
adding the cull-shrinking feature of SkBigPictures to SkMiniPictures.
Like SkBigPictures, shrink only when we're asked to build an R-tree.
(We don't actually build a tree for one rect, of course.)
We could do unconditionally, but SkPictureImageFilter uses the cull rect
as its crop. It's unclear to me what this image filter unit test I've
changed here was intending... had it had two draws we would have shrunk
its cull, but because it was hitting the 1-draw SkMiniPicture path it
kept the larger user-supplied cull.
As the test doesn't appear to have been written with cull shrinking in
mind, I've removed its SkRTreeFactory to keep that feature explicitly
disabled there.
BUG=skia:5974
Change-Id: I4118d2e85f2a69adef2e7a7fa9b9b8c17607a94f
Reviewed-on: https://skia-review.googlesource.com/12624
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Bug: skia:
Change-Id: I658a95576143d69656cd63aec44ff65d430d332f
Reviewed-on: https://skia-review.googlesource.com/13813
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Previously, SkPngCodec assumed that the stream only contained one
image, which ended at the end of the stream. It read the stream in
arbitrarily-sized chunks, and then passed that data to libpng for
processing.
If a stream contains more than one image, this may result in reading
beyond the end of the image, making future reads read the wrong data.
Now, SkPngCodec starts by reading 8 bytes at a time. After the
signature, 8 bytes is enough to know which chunk is next and how many
bytes are in the chunk.
When decoding the size, we stop when we reach IDAT, and when decoding
the image, we stop when we reach IEND.
This manual parsing is necessary to support APNG, which is planned in
the future. It also allows us to remove the SK_GOOGLE3_PNG_HACK, which
was a workaround for reading more than necessary at the beginning of
the image.
Add a test that simulates the issue, by decoding a special stream that
reports an error if the codec attempts to read beyond the end.
Temporarily disable the partial decoding tests for png. A larger change
will be necessary to get those working again, and no clients are
currently relying on incrementally decoding PNGs (i.e. decode part of
an image, then decode further with more data).
Bug: skia:5368
BUG:34073812
Change-Id: If832f7b20565411226fb5be3c305a4d16bf9269d
Reviewed-on: https://skia-review.googlesource.com/13900
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
This refactors from_half() and to_half() a bit, totally
reimplementing the non-hardware cases to be more clearly correct.
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Android-Clang-PixelC-CPU-TegraX1-arm64-Release-Android,Test-Android-Clang-Ci20-CPU-IngenicJZ4780-mipsel-Release-Android,Test-Android-Clang-Nexus10-CPU-Exynos5250-arm-Release-Android,Test-Mac-Clang-MacMini6.2-CPU-AVX-x86_64-Release,Test-Ubuntu-GCC-GCE-CPU-AVX2-x86-Debug,Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Debug
Change-Id: I439463cf90935c5e8fe2369cbcf45e07f3af62c7
Reviewed-on: https://skia-review.googlesource.com/13921
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Matt Sarett <msarett@google.com>
Have the callsites of SkOpTAllocator call SkArenaAlloc directly.
Bug: skia:
Change-Id: Ic54e92c3e9a0abed038aa3ae40e8a195895af99d
Reviewed-on: https://skia-review.googlesource.com/13870
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Herb Derby <herb@google.com>
I've tried a couple of ideas for approx_powf():
1) accumulate integer powers of x, then 4th roots, then 16th roots
2) continue 1) all the way to 256th roots
3) decompose into pow2 and log2, exploiting IEEE float layout
4) slightly tune constants used in 3)
5) accumulate integer powers of x, then 3+4) with different tuning
6) follow a source online, basically 5 with finesse
7) a new source quoting and improving on the method in 6).
7) seems perfect, enough that maybe we can explore improving its speed
at cost of precision. Might be nice to get rid of those divides. If we
allow a small tolerance (2-5) in our tests, we could use the very simple
fast forms from 3) (e.g. PS 5). I wish I had some images to look at!
Anything involving roots seems to be subverted by poor rsqrt precision.
This change of course affects the pipelines created by the tests for
exponential and full parametric gamma curves. What's less obvious is
that it also means SkJumper can now for the first time run the pipeline
created by the mixed gamma curves test. This means we now need to relax
our tolerance for the table-based channel, just like we did when
implementing table_{r,g,b,a}.
This took me an embarassingly long time to figure out. *face palm*
Change-Id: I451ee3c970a0a4a4e285f8aa8f6ef709a654d247
Reviewed-on: https://skia-review.googlesource.com/13656
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Matt Sarett <msarett@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Change-Id: I7fab6d1c7240c17f2cc8436e8c6e7c8d2df940bb
Reviewed-on: https://skia-review.googlesource.com/13814
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Test for degenerate values after computing the ratio, instead of
attempting to catch all tricky cases upfront.
BUG=skia:6511
Change-Id: I8e3421675994dd68a1eff1af3f1456917dd1f9e1
Reviewed-on: https://skia-review.googlesource.com/13726
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Change-Id: Id41d3e03390185f72b682225aeb140df45c84a34
Reviewed-on: https://skia-review.googlesource.com/13763
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
- On both GL and Vulkan, we must draw if writing to an MSAA surface.
Otherwise we just write to the resolve target texture, which gets
overwritten on the next resolve.
- On Vulkan, we must draw if the target isn't a texture. (This check
was already present in onWritePixels).
- On Vulkan, when reading from an MSAA surface as a different config,
we don't need the readConfig to be renderable with MSAA - the temp
surface is always created non-MSAA.
- Added tests for these fixes, verified that they failed previously.
Bug: skia:
Change-Id: Ia2d5025d7a8f8de8630413453f83b58028dd41aa
Reviewed-on: https://skia-review.googlesource.com/13691
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
A pair of coincident lines can generate multiple intersection
points. Path ops is more stable when the intersection T value
is used to recompute the intersection point, but this has
the side-effect of making integral edges intersect at non-integral
values.
While it's worthwhile to fix this, for the moment it is less
disruptive to only worry about keeping intersection values
integral if the original intersection point is integral in
both axes.
Also, fix some debugging code that bit-rotted.
R=msarett@google.com
Change-Id: Iefd27b25d1d21c22b224c174bd59bc6c105033c4
Reviewed-on: https://skia-review.googlesource.com/13721
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Cary Clark <caryclark@google.com>
This is mainly so writeSurfacePixels can have continuity of surfaceContext when it draws.
Change-Id: I34f1dc5c4c3dcfa7bf91aa3ad72b7a48ed9de1a9
Reviewed-on: https://skia-review.googlesource.com/13595
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
In testing, it didn't really seem like we're getting anything out of
doing an interpolated lookup, so this just does a single rounded lookup.
Change-Id: If85ba68675945b442076519dd7f1bf7540d1628d
Reviewed-on: https://skia-review.googlesource.com/13646
Commit-Queue: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Matt Sarett <msarett@google.com>
This reverts commit cd11c809f2.
Reason for revert: assert(rtp->getLastOpList())
Original change's description:
> Split cleanup changes out of bigger CL
>
> This are split out of: https://skia-review.googlesource.com/c/11581/ (Split up opLists)
>
> TBR=bsalomon@google.com
>
> Change-Id: I1239e806a30a93d3c17ad933f118b98a5077dd3a
> Reviewed-on: https://skia-review.googlesource.com/13585
> Commit-Queue: Robert Phillips <robertphillips@google.com>
> Reviewed-by: Greg Daniel <egdaniel@google.com>
>
TBR=egdaniel@google.com,bsalomon@google.com,robertphillips@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: Ia3ef7322fe830a6a4dc29226ce931d35d181c6e0
Reviewed-on: https://skia-review.googlesource.com/13641
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This matches other Skia APIs. size_t was adopted from blink/
GIFImageReader.
Change-Id: Ic83e59f0942f597c4fb834e623acd9886ad483fe
Reviewed-on: https://skia-review.googlesource.com/13274
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Reviewed-by: Chris Blume <cblume@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
Fixes 3 gms in gbr-8888. Breaks 0 gms in gbr-8888.
Bug: skia:
Change-Id: I3365390b16353821ef6057a7bb68020887e36f72
Reviewed-on: https://skia-review.googlesource.com/13323
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Prior to e132e7be5f, calling getFrameInfo
on an SkGifCodec which was truncated before fully parsing the local
color map of the first frame would hit an assert. Add a test to verify
that the problem has been fixed.
Modify box.gif to use a local color map for the first (and only) frame.
Change-Id: I905afe60c0c6ecc82e251e00ef82b2e5b22975a3
Reviewed-on: https://skia-review.googlesource.com/13320
Reviewed-by: Chris Blume <cblume@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
guarded by SK_SUPPORT_OBSOLETE_LOCKPIXELS
needs https://codereview.chromium.org/2820873002/# to land first
Bug: skia:6481
Change-Id: I1c39902cbf6fe99f622adfa8192733b95f7fea09
Change-Id: I1c39902cbf6fe99f622adfa8192733b95f7fea09
Reviewed-on: https://skia-review.googlesource.com/13580
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Make the constructors for SkArenaAlloc unambiguous.
TBR=mtklein@google.com
Change-Id: Iaa6419574e78e17bf746f5f9bcdf99c9d6c9d727
Reviewed-on: https://skia-review.googlesource.com/13540
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Herb Derby <herb@google.com>
Change-Id: I657c489c56b93765567be69076fb4c3d526e55a5
Reviewed-on: https://skia-review.googlesource.com/13068
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
- Updates the logic to reflect the Loop-Blinn paper instead of the GPU
gems website.
- Removes the threshold for detecting local cusps. The serpentine
codepath works for these cusps anyway, so what we really want to know
is whether the discriminant is negative.
- Makes sure to not scale the inflection function by 1/0.
- Shifts the inflection function coefficients in d[] so they match the
paper.
- Stores the cubic discriminant in d[0].
Bug: skia:
Change-Id: I909a522a0fd27c9c8dfbc27d968bc43eeb7a416f
Reviewed-on: https://skia-review.googlesource.com/13304
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Using std::string is tons faster than SkString;
multiple callers to std::string don't run into
thread contention but SkString does.
R=csmartdalton@google.com
Change-Id: I0357c6a9c73856bfffbb76e65c275acdfe7d8159
Reviewed-on: https://skia-review.googlesource.com/13471
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Commit-Queue: Cary Clark <caryclark@google.com>
This new unittest would assert before this fix.
Bug: skia:6501
Change-Id: I351ad03f29bccc054f72bfcb838174830dbd008c
Reviewed-on: https://skia-review.googlesource.com/13413
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
It fails at line 336:
REPORTER_ASSERT(reporter, configs[i]->getBackend().equals(expectedConfigs[i].backend));
Change-Id: Iab71162b9d7b5454d200cb373026992eac92adf8
Reviewed-on: https://skia-review.googlesource.com/13406
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
It thinks it should fail, but it doesn't.
Change-Id: Ie97f57dd7a9040a817b59186b2f8fa704bdda3e9
Reviewed-on: https://skia-review.googlesource.com/13404
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
