| e4ba1059ddf4d9a1e41b01c378f1a5cc15669343 |
|
30-Jan-2017 |
Leon Scroggins III <scroggo@google.com> |
GIF: Only report a frame after knowing dependency
Previously, getFrameInfo might report a frame that was truncated prior
to setting its requiredFrame. As a result, fRequiredFrame may be
different depending on how much data has already been received.
If there is a local color table, do not report the frame until the
color table has been received, since that is used to determine
fRequiredFrame. If there is no local color table, set fRequiredFrame
and report the frame after reading the header.
Add a test.
Replace make_from_resource with GetResourceAsData
Change-Id: I1b697f766c1d0e1e12ab2ae1d27167af5193395d
Reviewed-on: https://skia-review.googlesource.com/7756
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
/external/skia/third_party/gif/SkGifImageReader.cpp
|
| b0b625b79605ab0a18aa038f3f87e88da2441c16 |
|
22-Dec-2016 |
Leon Scroggins III <scroggo@google.com> |
GIF: Better check for frame dependency
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>
/external/skia/third_party/gif/SkGifImageReader.cpp
|
| 932efed7c89c69616e283fdfef65e86b9d9da381 |
|
16-Dec-2016 |
Leon Scroggins III <scroggo@google.com> |
GIF: Avoid copying/storing data when possible
If the input SkStream has a length and position, do not copy and store
LZW blocks or ColorMaps. Instead, mark the position and size, and read
from the stream when necessary.
This will save memory in Chromium's use case, which has already
buffered all of its data.
In the case where we *do* need to copy, store it on the SkStreamBuffer.
This allows SkGifImageReader to have simpler code.
Add tests.
Change-Id: Ic65fa766328ae2e5974b2084bc2099e19aced731
Reviewed-on: https://skia-review.googlesource.com/6157
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
/external/skia/third_party/gif/SkGifImageReader.cpp
|
| 4993b95f532fdfc1996809189aa7e24ee839d983 |
|
08-Dec-2016 |
Leon Scroggins III <scroggo@google.com> |
Do not create SkGifCodec if true size is not known
If there is enough data in the stream to read the reported canvas size,
but not enough to read the first image's header, we do not know the
true canvas size, since we may expand it to fit the first frame. In
that case, return nullptr from NewFromStream.
Add a test.
SkGifCodec.cpp:
Correct a comment - parse returns false if there is a fatal error.
parse() returning true does not guarantee that the size was found.
Instead of checking the width and height, check to see whether the
first frame exists and has its header defined. If not, we do not yet
know the true canvas size. Assert that the canvas size is non-zero,
which is a fatal error from parse.
SkGifImageReader.cpp:
Move the code to set the header defined before the SkGIFSizeQuery exit
condition. This allows SkGifCodec to check the first frame's header to
determine whether the size is known.
GifTest.cpp:
Add a test which truncates the file just before the image header (and
after the global header). Prior to the other changes, this would create
an SkCodec. For an image that needs its canvas size expanded, the
SkCodec would have an incorrect size.
CodecPartialTest.cpp:
randPixels.gif now needs more than half of its data to create an
SkCodec, so set a minimum for test_partial.
Change-Id: I40482f524128b2f1fe59b8f27dd64c7cbe793079
Reviewed-on: https://skia-review.googlesource.com/5701
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Leon Scroggins <scroggo@google.com>
/external/skia/third_party/gif/SkGifImageReader.cpp
|
| 45565b676c86d6b4955b8643236880b016772e95 |
|
05-Dec-2016 |
Leon Scroggins III <scroggo@google.com> |
GIF: Internal cleanup - remove color map parameter
SkGIFFrameContext::decode() and SkGIFLZWContext::prepareToDecode() do
not need (or use) the global color map, so stop passing it as a
parameter. The parameter was used prior to
https://skia-review.googlesource.com/c/4379/ (different issue!), but we
overlooked removing it then.
Change-Id: I0f477e9db11f7650938d6b868baef69e3b37d86b
Reviewed-on: https://skia-review.googlesource.com/5609
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
/external/skia/third_party/gif/SkGifImageReader.cpp
|
| 4ef986db65027f53999174279252092ba9b03c9e |
|
03-Nov-2016 |
Matt Sarett <msarett@google.com> |
Write transparent pixels more often in SkGifImageReader
This stems from a behavior difference between Skia and Chrome.
In Skia, we want to write transparent pixels as often as possible.
(It's faster than checking if we should skip each pixel.)
In Chrome, they avoid writing transparent pixels unless
absolutely necessary.
We were cautious about changing behavior when this first landed,
but this is easier to think about in a smaller change (right now).
(1) We can always write transparent pixels when we are writing
an independent frame.
(2) There is no need for the progressiveDisplay() check. We
only ever use progressive display methods on the first
frame - and the first frame is always independent.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4379
Change-Id: I82048a08e2003aac216f483c7db8df997b687149
Reviewed-on: https://skia-review.googlesource.com/4379
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
/external/skia/third_party/gif/SkGifImageReader.cpp
|
| e71b1a1496738ebce4a8cac4ffa5ee1413996542 |
|
01-Nov-2016 |
scroggo <scroggo@chromium.org> |
Report repetition count in SkCodec
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
/external/skia/third_party/gif/SkGifImageReader.cpp
|
| 2f7068aec9906168b3c142b5057e098114376cc9 |
|
31-Oct-2016 |
scroggo <scroggo@chromium.org> |
Treat a GIF with no color table as transparent
When checking to see whether a GIF has transparency to determine its
alpha type, treat an empty color table as having alpha, since we
will draw it as a transparent image.
(This is a separate bug from skbug.com/5883, but the image I used to
verify that bug was drawn to 565 as black. The fix is to not support
565 in that case, by changing its recommended alpha type.)
BUG=skia:5883
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2461813002
Review-Url: https://codereview.chromium.org/2461813002
/external/skia/third_party/gif/SkGifImageReader.cpp
|
| 53f63b69e83fd805418d72a6eeb860cf0fcff3c5 |
|
27-Oct-2016 |
scroggo <scroggo@chromium.org> |
Fix decoding GIF to 565
565 cannot take the !writeTransparentPixels path, so disable it for
cases where we might have to take that path.
This only affects frames beyond the first. If the first frame has
a transparent pixel, it will be marked as non-opaque, so we cannot
decode to 565 anyway.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2441833002
Review-Url: https://codereview.chromium.org/2441833002
/external/skia/third_party/gif/SkGifImageReader.cpp
|
| 1285f413950910782d5439b5072ccfa14bdf80f7 |
|
26-Oct-2016 |
scroggo <scroggo@chromium.org> |
Write transparent pixels more often (SkGifCodec)
Writing transparent pixels is faster than the alternative, and we can
skip clearing the frame to transparent. We'll still clear if the image
is incomplete.
I ran
./out/Release/nanobench --images <images> --samples 100 --sourceType image --simpleCodec -v
over the GIFs we have on our bots, and found an average ~13% speedup.
Raw data is on sheet 2 of
https://docs.google.com/spreadsheets/d/19V-t9BfbFw5eiwBTKA1qOBkZbchjlTC5EIz6HFy-6RI/
(the sheet is named WriteTransparentPixels).
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2436183002
Review-Url: https://codereview.chromium.org/2436183002
/external/skia/third_party/gif/SkGifImageReader.cpp
|
| 3cfdf6c8b1f0c6ebe59ddd0d2750976c2dd1921d |
|
26-Oct-2016 |
Jim Van Verth <jvanverth@google.com> |
Fix some Windows warnings
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3980
Change-Id: Icfc5dfb985b966c625d9bc81f61719ac5549085e
Reviewed-on: https://skia-review.googlesource.com/3980
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
/external/skia/third_party/gif/SkGifImageReader.cpp
|
| f9acbe28953634c25c4171fd6d5a81976f8c8f38 |
|
25-Oct-2016 |
scroggo <scroggo@chromium.org> |
Fix more namespace conflicts in SkGifImageReader
To fix Google3
TBR=benjaminwagner@google.com
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2450753003
NOTREECHECKS=true
Review-Url: https://codereview.chromium.org/2450753003
/external/skia/third_party/gif/SkGifImageReader.cpp
|
| 3d3a65c488162ef1db0b35adf3235d012b04c88d |
|
24-Oct-2016 |
scroggo <scroggo@chromium.org> |
Rename GIFImageReader to SkGifImageReader
The former could violate One Definition Rule in Google3, since other
projects that are based on Chrome/webkit also have GIFImageReader.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2445653004
Review-Url: https://codereview.chromium.org/2445653004
/external/skia/third_party/gif/SkGifImageReader.cpp
|