aboutsummaryrefslogtreecommitdiffhomepage
path: root/gm/animatedGif.cpp
Commit message (Collapse)AuthorAge
* use unique_ptr for codec factoriesGravatar Mike Reed2017-07-25
| | | | | | | | | | Will need guards for android (at least) Bug: skia: Change-Id: I2bb8e656997984489ef1f2e41cd3d301c4e7b947 Reviewed-on: https://skia-review.googlesource.com/26040 Reviewed-by: Mike Klein <mtklein@chromium.org> Commit-Queue: Mike Reed <reed@google.com>
* Reland "Remove support for decoding to kIndex_8"Gravatar Leon Scroggins2017-07-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Original change's description: > > Remove support for decoding to kIndex_8 > > > > Fix up callsites, and remove tests that no longer make sense. > > > > Bug: skia:6828 > > Change-Id: I2548c4b7528b7b1be7412563156f27b52c9d4295 > > Reviewed-on: https://skia-review.googlesource.com/21664 > > Reviewed-by: Derek Sollenberger <djsollen@google.com> > > Commit-Queue: Leon Scroggins <scroggo@google.com> > > TBR=djsollen@google.com,scroggo@google.com > > Change-Id: I1bc669441f250690884e75a9a61427fdf75c6907 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: skia:6828 > Reviewed-on: https://skia-review.googlesource.com/22120 > Reviewed-by: Leon Scroggins <scroggo@google.com> > Commit-Queue: Leon Scroggins <scroggo@google.com> TBR=djsollen@google.com,scroggo@google.com Bug: skia:6828 Change-Id: I36ff5a11c529d29e8adc95f43b8edc6fd1dbf5b8 Reviewed-on: https://skia-review.googlesource.com/22320 Reviewed-by: Leon Scroggins <scroggo@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
* Revert "Remove support for decoding to kIndex_8"Gravatar Leon Scroggins2017-07-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 742a3e298fda669006147e4a305bab8452369b1f. Reason for revert: Breaking Android roll: frameworks/base/core/jni/android/graphics/BitmapFactory.cpp:453:18: error: no member named 'fColorPtr' in 'SkAndroidCodec::AndroidOptions' codecOptions.fColorPtr = colorPtr; ~~~~~~~~~~~~ ^ frameworks/base/core/jni/android/graphics/BitmapFactory.cpp:454:18: error: no member named 'fColorCount' in 'SkAndroidCodec::AndroidOptions' codecOptions.fColorCount = colorCount; ~~~~~~~~~~~~ ^ Original change's description: > Remove support for decoding to kIndex_8 > > Fix up callsites, and remove tests that no longer make sense. > > Bug: skia:6828 > Change-Id: I2548c4b7528b7b1be7412563156f27b52c9d4295 > Reviewed-on: https://skia-review.googlesource.com/21664 > Reviewed-by: Derek Sollenberger <djsollen@google.com> > Commit-Queue: Leon Scroggins <scroggo@google.com> TBR=djsollen@google.com,scroggo@google.com Change-Id: I1bc669441f250690884e75a9a61427fdf75c6907 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia:6828 Reviewed-on: https://skia-review.googlesource.com/22120 Reviewed-by: Leon Scroggins <scroggo@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
* Remove support for decoding to kIndex_8Gravatar Leon Scroggins III2017-07-10
| | | | | | | | | | Fix up callsites, and remove tests that no longer make sense. Bug: skia:6828 Change-Id: I2548c4b7528b7b1be7412563156f27b52c9d4295 Reviewed-on: https://skia-review.googlesource.com/21664 Reviewed-by: Derek Sollenberger <djsollen@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
* Make SkCodec more flexible about its required frameGravatar Leon Scroggins III2017-06-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SkCodec sets fRequiredFrame to be the earliest possible frame that a given frame can depend on. e.g. - Frame A fills the screen, Keep - Frame B does not cover A, Keep - Frame C covers B but not A, and is opaque Frame C can depend on either A or B. SkCodec already reports that C depends on A. This CL allows a client of SkCodec to use either A or B to create C. Also expose the DisposalMethod. Since any frame between A and C can be used to create C except for DisposePrevious frames, the client needs to be able to know the disposal method so they do not try to use such a frame to create C. Further, the disposal method can be used to give the client a better idea whether they will continue to need a frame. (e.g. if frame i is DisposePrevious and depends on i-1, the client may not want to steal i-1 to create i, since i+1 may also depend on i-1.) TODO: Share code for decoding prior frames between GIF and WEBP Change-Id: I91a5ae22ba3d8dfbe0bde833fa67ae3da0d81ed6 Reviewed-on: https://skia-review.googlesource.com/13722 Reviewed-by: Mike Reed <reed@google.com> Reviewed-by: Chris Blume <cblume@chromium.org> Reviewed-by: Matt Sarett <msarett@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
* add drawString helper to canvasGravatar Cary Clark2017-04-28
| | | | | | | | | | | | | | | | | | Many tests and examples use drawText with a guess of how long the text is in bytes, or a call to strlen(). Add a helper to SkCanvas to simplify these examples. Add another helper for SkString. R=reed@google.com Change-Id: I0204a31e938f065606f08ee7cd9a6b36db791ee2 Reviewed-on: https://skia-review.googlesource.com/13642 Commit-Queue: Cary Clark <caryclark@google.com> Reviewed-by: Cary Clark <caryclark@google.com> Reviewed-by: Mike Reed <reed@google.com> Reviewed-by: Cary Clark <caryclark@skia.org>
* Revert "Revert "Delete copyTo(Allocator), hide copyTo() behind flag""Gravatar Matt Sarett2017-04-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 0122af08f6af0dee490e1a4f35b552377d0d4753. Reason for revert: Fixed Android callsite Original change's description: > Revert "Delete copyTo(Allocator), hide copyTo() behind flag" > > This reverts commit d4a338f4d0a0cdc08d7d3668931c60997f0fa971. > > Reason for revert: Looks like I missed something I was supposed to delete in Android. > > Original change's description: > > Delete copyTo(Allocator), hide copyTo() behind flag > > > > Replace uses of copyTo() in Skia. > > > > Bug: skia:6464 > > Change-Id: I921dc53a1c29a5176d18f05741f7c0b5a008e548 > > Reviewed-on: https://skia-review.googlesource.com/14502 > > Commit-Queue: Matt Sarett <msarett@google.com> > > Reviewed-by: Mike Reed <reed@google.com> > > > > TBR=msarett@google.com,reed@google.com > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > > Change-Id: I4d252940cc6a2462b030007055ea6c229471fc6e > Reviewed-on: https://skia-review.googlesource.com/14602 > Reviewed-by: Matt Sarett <msarett@google.com> > Commit-Queue: Matt Sarett <msarett@google.com> > TBR=msarett@google.com,reviews@skia.org,reed@google.com Change-Id: I81659a820f79f1958fda23cb62513065b57db99d Reviewed-on: https://skia-review.googlesource.com/14640 Commit-Queue: Matt Sarett <msarett@google.com> Reviewed-by: Matt Sarett <msarett@google.com>
* Revert "Delete copyTo(Allocator), hide copyTo() behind flag"Gravatar Matt Sarett2017-04-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit d4a338f4d0a0cdc08d7d3668931c60997f0fa971. Reason for revert: Looks like I missed something I was supposed to delete in Android. Original change's description: > Delete copyTo(Allocator), hide copyTo() behind flag > > Replace uses of copyTo() in Skia. > > Bug: skia:6464 > Change-Id: I921dc53a1c29a5176d18f05741f7c0b5a008e548 > Reviewed-on: https://skia-review.googlesource.com/14502 > Commit-Queue: Matt Sarett <msarett@google.com> > Reviewed-by: Mike Reed <reed@google.com> > TBR=msarett@google.com,reed@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I4d252940cc6a2462b030007055ea6c229471fc6e Reviewed-on: https://skia-review.googlesource.com/14602 Reviewed-by: Matt Sarett <msarett@google.com> Commit-Queue: Matt Sarett <msarett@google.com>
* Delete copyTo(Allocator), hide copyTo() behind flagGravatar Matt Sarett2017-04-27
| | | | | | | | | | Replace uses of copyTo() in Skia. Bug: skia:6464 Change-Id: I921dc53a1c29a5176d18f05741f7c0b5a008e548 Reviewed-on: https://skia-review.googlesource.com/14502 Commit-Queue: Matt Sarett <msarett@google.com> Reviewed-by: Mike Reed <reed@google.com>
* Switch SkCodec to int for counts and indicesGravatar Leon Scroggins III2017-04-17
| | | | | | | | | | | | 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>
* Fix some Windows warningsGravatar Jim Van Verth2016-10-26
| | | | | | | | | | | 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>
* Clear background to white in animatedGif GMGravatar scroggo2016-10-24
| | | | | | | White looks the same in 565, reducing the number of differences in gold GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2447793002 Review-Url: https://codereview.chromium.org/2447793002
* Add support for multiple frames in SkCodecGravatar scroggo2016-10-24
Add an interface to decode frames beyond the first in SkCodec, and add an implementation for SkGifCodec. Add getFrameData to SkCodec. This method reads ahead in the stream to return a vector containing meta data about each frame in the image. This is not required in order to decode frames beyond the first, but it allows a client to learn extra information: - how long the frame should be displayed - whether a frame should be blended with a prior frame, allowing the client to provide the prior frame to speed up decoding Add a new fields to SkCodec::Options: - fFrameIndex - fHasPriorFrame The API is designed so that SkCodec never caches frames. If a client wants a frame beyond the first, they specify the frame in Options.fFrameIndex. If the client does not have the frame's required frame (the frame that this frame must be blended on top of) cached, they pass false for Options.fHasPriorFrame. Unless the frame is independent, the codec will then recursively decode all frames necessary to decode fFrameIndex. If the client has the required frame cached, they can put it in the dst they pass to the codec, and the codec will only draw fFrameIndex onto it. Replace SkGifCodec's scanline decoding support with progressive decoding, and update the tests accordingly. Implement new APIs in SkGifCodec. Instead of using gif_lib, use GIFImageReader, imported from Chromium (along with its copyright headers) with the following changes: - SkGifCodec is now the client - Replace blink types - Combine GIFColorMap::buildTable and ::getTable into a method that creates and returns an SkColorTable - Input comes from an SkStream, instead of a SegmentReader. Add SkStreamBuffer, which buffers the (potentially partial) stream in order to decode progressively. (FIXME: This requires copying data that previously was read directly from the SegmentReader. Does this hurt performance? If so, can we fix it?) - Remove UMA code - Instead of reporting screen width and height to the client, allow the client to query for it - Fail earlier if the first frame AND screen have size of zero - Compute required previous frame when adding a new one - Move GIFParseQuery from GIFImageDecoder to GIFImageReader - Allow parsing up to a specific frame (to skip parsing the rest of the stream if a client only wants the first frame) - Compute whether the first frame has alpha and supports index 8, to create the SkImageInfo. This happens before reporting that the size has been decoded. Add GIFImageDecoder::haveDecodedRow to SkGifCodec, imported from Chromium (along with its copyright header), with the following changes: - Add support for sampling - Use the swizzler - Keep track of the rows decoded - Do *not* keep track of whether we've seen alpha Remove SkCodec::kOutOfOrder_SkScanlineOrder, which was only used by GIF scanline decoding. Call onRewind even if there is no stream (SkGifCodec needs to clear its decoded state so it will decode from the beginning). Add a method to SkSwizzler to access the offset into the dst, taking subsetting into account. Add a GM that animates a GIF. Add tests for the new APIs. *** Behavior changes: * Previously, we reported that an image with a subset frame and no transparent index was opaque and used the background index (if present) to fill the background. This is necessary in order to support index 8, but it does not match viewers/browsers I have seen. Examples: - Chromium and Gimp render the background transparent - Firefox, Safari, Linux Image Viewer, Safari Preview clip to the frame (for a single frame image) This CL matches Chromium's behavior and renders the background transparent. This allows us to have consistent behavior across products and simplifies the code (relative to what we would have to do to continue the old behavior on Android). It also means that we will no longer support index 8 for some GIFs. * Stop checking for GIFSTAMP - all GIFs should be either 89a or 87a. This matches Chromium. I suspect that bugs would have been reported if valid GIFs started with "GIFVER" instead of "GIF89a" or "GIF87a" (but did not decode in Chromium). *** Future work not included in this CL: * Move some checks out of haveDecodedRow, since they are the same for the entire frame e.g. - intersecting the frameRect with the full image size - whether there is a color table * Change when we write transparent pixels - In some cases, Chromium deemed this unnecessary, but I suspect it is slower than the fallback case. There will continue to be cases where we should *not* write them, but for e.g. the first pass where we have already cleared to transparent (which we may also be able to skip) writing the transparent pixels will not make anything incorrect. * Report color type and alpha type per frame - Depending on alpha values, disposal methods, frame rects, etc, subsequent frames may have different properties than the first. * Skip copies of the encoded data - We copy the encoded data in case the stream is one that cannot be rewound, so we can parse and then decode (possibly not immediately). For some input streams, this is unnecessary. - I was concerned this cause a performance regression, but on average the new code is faster than the old for the images I tested [1]. - It may cause a performance regression for Chromium, though, where we can always move back in the stream, so this should be addressed. Design doc: https://docs.google.com/a/google.com/document/d/12Qhf9T92MWfdWujQwCIjhCO3sw6pTJB5pJBwDM1T7Kc/ [1] https://docs.google.com/a/google.com/spreadsheets/d/19V-t9BfbFw5eiwBTKA1qOBkZbchjlTC5EIz6HFy-6RI/ GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=2045293002 Review-Url: https://codereview.chromium.org/2045293002