skia2/include/codec/SkCodec.h

926 lines
34 KiB
C
Raw Normal View History

/*
* Copyright 2015 Google Inc.
*
* Use of this source code is governed by a BSD-style license that can be
* found in the LICENSE file.
*/
#ifndef SkCodec_DEFINED
#define SkCodec_DEFINED
#include "../private/SkNoncopyable.h"
#include "../private/SkTemplates.h"
#include "../private/SkEncodedInfo.h"
#include "SkCodecAnimation.h"
#include "SkColor.h"
#include "SkEncodedImageFormat.h"
#include "SkEncodedOrigin.h"
#include "SkImageInfo.h"
Revert[4] "apply codec origin in generator" This reverts commit dd340146f1fe7414702d6fea251da989d425691e. Reason for revert: ios gn file fixed Original change's description: > Revert "Revert "Revert "apply codec origin in generator""" > > This reverts commit 82269abfec798621c8dbbc6bd48996c0b2686f41. > > Reason for revert: ios build needs include path for SkCodec.h > > Original change's description: > > Revert "Revert "apply codec origin in generator"" > > > > This reverts commit 363dd988a55c2ed3fa92e2368c1c889101425734. > > > > Reason for revert: pdfium fix landed > > > > Original change's description: > > > Revert "apply codec origin in generator" > > > > > > This reverts commit fa15877f487333bec876e7315cf584c0d598d098. > > > > > > Reason for revert: Appears to break PDFium. > > > > > > Original change's description: > > > > apply codec origin in generator > > > > > > > > Bug: skia: > > > > Change-Id: I383dacb49b1e3c88467ccdbf3288764bb1bbf01a > > > > Reviewed-on: https://skia-review.googlesource.com/58600 > > > > Reviewed-by: Leon Scroggins <scroggo@google.com> > > > > Commit-Queue: Mike Reed <reed@google.com> > > > > > > TBR=scroggo@google.com,reed@google.com > > > > > > Change-Id: Id97137d6ec39ca638c941928bae6510814b1c499 > > > No-Presubmit: true > > > No-Tree-Checks: true > > > No-Try: true > > > Bug: skia: > > > Reviewed-on: https://skia-review.googlesource.com/60041 > > > Reviewed-by: Ben Wagner <benjaminwagner@google.com> > > > Commit-Queue: Ben Wagner <benjaminwagner@google.com> > > > > TBR=benjaminwagner@google.com,scroggo@google.com,reed@google.com > > > > Change-Id: I1b54a6e6e6cbda07f346ffbbc4977f9db705abcd > > No-Presubmit: true > > No-Tree-Checks: true > > No-Try: true > > Bug: skia: > > Reviewed-on: https://skia-review.googlesource.com/60320 > > Reviewed-by: Mike Reed <reed@google.com> > > Commit-Queue: Mike Reed <reed@google.com> > > TBR=benjaminwagner@google.com,scroggo@google.com,reed@google.com > > Change-Id: I4c2d310521d1a678b407d30b9fe3c261c49d67bc > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: skia: > Reviewed-on: https://skia-review.googlesource.com/60560 > Reviewed-by: Mike Reed <reed@google.com> > Commit-Queue: Mike Reed <reed@google.com> TBR=benjaminwagner@google.com,scroggo@google.com,reed@google.com Change-Id: I5c1e53aff3ad174b0d4a806c35b7cdcd194479d7 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia: Reviewed-on: https://skia-review.googlesource.com/60563 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Reed <reed@google.com>
2017-10-17 18:04:32 +00:00
#include "SkPixmap.h"
#include "SkSize.h"
#include "SkStream.h"
#include "SkTypes.h"
#include "SkYUVASizeInfo.h"
Add support for multiple frames in SkCodec 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
2016-10-24 16:03:26 +00:00
#include <vector>
class SkColorSpace;
class SkData;
Consolidate decoding frames into SkCodec Add a new private method to SkCodec that handles Options.fFrameIndex: - Check to ensure the index is valid - Call onGetFrameCount to force parsing the stream - Recursively call getPixels (it should be complete, so no need for incremental decoding) to decode the prior frame if necessary - Zero fill a RestoreBGColor frame Call the method in getPixels and startIncrementalDecode, and remove duplicate code from GIF and WEBP. Remove support for scaling frames beyond the first, which is currently unused. Preserve the feature of SkGifCodec that it will only parse to the end of the first frame if the first frame is asked for. (Also note that when we continue a partial frame, we won't force parsing the full stream.) If the client only wants the first frame, parsing the rest would be unnecessary. But if the client wants the second, we assume they will want any remaining frames, so we parse the remainder of the stream. This simplifies the code (so SkCodec does not have to ask its subclass to parse up to a particular frame). Update tests that relied on the old behavior: - Codec_partialAnim now hardcodes the bytes needed. Previously it relied on the old behavior that GIF only parsed up to the frame being decoded. - Codec_skipFullParse now only tests the first frame, since that is the case where it is important to skip a full parse. TBR=reed@google.com No changes to the public API. Change-Id: Ic2f075452dfeedb4e3e60e6cf4df33ee7bd38495 Reviewed-on: https://skia-review.googlesource.com/19276 Reviewed-by: Leon Scroggins <scroggo@google.com> Reviewed-by: Matt Sarett <msarett@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
2017-06-12 20:41:09 +00:00
class SkFrameHolder;
class SkPngChunkReader;
class SkSampler;
namespace DM {
Make SkPngCodec decode progressively. This is a step towards using SkCodec in Chromium, where progressive decoding is necessary. Switch from using png_read_row (which expects all the data to be available) to png_process_data, which uses callbacks when rows are available. Create a new API for SkCodec, which supports progressive decoding and scanline decoding. Future changes will switch the other clients off of startScanlineDecode and get/skip-Scanlines to the new API. Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced PNG images. In the new API, interlaced PNG fits kTopDown. Also remove updateCurrScanline(), which was only used by the old implementation for interlaced PNG. DMSrcSink: - In CodecSrc::kScanline_Mode, use the new method for scanline decoding for the supported formats (just PNG and PNG-in-ICO for now). fuzz.cpp: - Remove reference to kNone_ScanlineOrder SkCodec: - Add new APIs: - startIncrementalDecode - incrementalDecode - Remove kNone_SkScanlineOrder and updateCurrScanline() - Set fDstInfo and fOptions in getPixels(). This may not be necessary for all implementations, but it simplifies things for SkPngCodec. SkPngCodec: - Implement new APIs - Switch from sk_read_fn/png_read_row etc to png_process_data - Expand AutoCleanPng's role to decode the header and create the SkPngCodec - Make the interlaced PNG decoder report how many lines were initialized during an incomplete decode SkIcoCodec: - Implement the new APIs; supported for PNG in ICO SkSampledCodec: - Call the new method for decoding scanlines, and fall back to the old method if the new version is unimplemented - Remove references to kNone_SkScanlineOrder tests/CodecPartial: - Add a test which decodes part of an image, then finishes the decode, and compares it to the straightforward method tests/CodecTest: - Add a test which decodes all scanlines using the new method - Repurpose the Codec_stripes test to decode using the new method in sections rather than all at once - In the method check(), add a parameter for whether the image supports the new method of scanline decoding, and be explicit about whether an image supports incomplete - Test incomplete PNG decodes. We should have been doing it anyway for non-interlaced (except for an image that is too small - one row), but the new method supports interlaced incomplete as well - Make test_invalid_parameters test the new method - Add a test to ensure that it's safe to fall back to scanline decoding without rewinding BUG=skia:4211 The new version was generally faster than the old version (but not significantly so). Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/ Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/ GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003 Review-Url: https://codereview.chromium.org/1997703003
2016-09-16 15:20:38 +00:00
class CodecSrc;
class ColorCodecSrc;
}
/**
* Abstraction layer directly on top of an image codec.
*/
class SK_API SkCodec : SkNoncopyable {
public:
/**
* Minimum number of bytes that must be buffered in SkStream input.
*
* An SkStream passed to NewFromStream must be able to use this many
* bytes to determine the image type. Then the same SkStream must be
* passed to the correct decoder to read from the beginning.
*
* This can be accomplished by implementing peek() to support peeking
* this many bytes, or by implementing rewind() to be able to rewind()
* after reading this many bytes.
*/
static constexpr size_t MinBufferedBytesNeeded() { return 32; }
/**
* Error codes for various SkCodec methods.
*/
enum Result {
/**
* General return value for success.
*/
kSuccess,
/**
* The input is incomplete. A partial image was generated.
*/
kIncompleteInput,
/**
* Like kIncompleteInput, except the input had an error.
*
* If returned from an incremental decode, decoding cannot continue,
* even with more data.
*/
kErrorInInput,
/**
* The generator cannot convert to match the request, ignoring
* dimensions.
*/
kInvalidConversion,
/**
* The generator cannot scale to requested size.
*/
kInvalidScale,
/**
* Parameters (besides info) are invalid. e.g. NULL pixels, rowBytes
* too small, etc.
*/
kInvalidParameters,
/**
* The input did not contain a valid image.
*/
kInvalidInput,
/**
* Fulfilling this request requires rewinding the input, which is not
* supported for this input.
*/
kCouldNotRewind,
/**
* An internal error, such as OOM.
*/
kInternalError,
/**
* This method is not implemented by this codec.
* FIXME: Perhaps this should be kUnsupported?
*/
kUnimplemented,
};
/**
* Readable string representing the error code.
*/
static const char* ResultToString(Result);
/**
* If this stream represents an encoded image that we know how to decode,
* return an SkCodec that can decode it. Otherwise return NULL.
*
* As stated above, this call must be able to peek or read
* MinBufferedBytesNeeded to determine the correct format, and then start
* reading from the beginning. First it will attempt to peek, and it
* assumes that if less than MinBufferedBytesNeeded bytes (but more than
* zero) are returned, this is because the stream is shorter than this,
* so falling back to reading would not provide more data. If peek()
* returns zero bytes, this call will instead attempt to read(). This
* will require that the stream can be rewind()ed.
*
* If Result is not NULL, it will be set to either kSuccess if an SkCodec
* is returned or a reason for the failure if NULL is returned.
*
* If SkPngChunkReader is not NULL, take a ref and pass it to libpng if
* the image is a png.
*
* If the SkPngChunkReader is not NULL then:
* If the image is not a PNG, the SkPngChunkReader will be ignored.
* If the image is a PNG, the SkPngChunkReader will be reffed.
* If the PNG has unknown chunks, the SkPngChunkReader will be used
* to handle these chunks. SkPngChunkReader will be called to read
* any unknown chunk at any point during the creation of the codec
* or the decode. Note that if SkPngChunkReader fails to read a
* chunk, this could result in a failure to create the codec or a
* failure to decode the image.
* If the PNG does not contain unknown chunks, the SkPngChunkReader
* will not be used or modified.
*
* If NULL is returned, the stream is deleted immediately. Otherwise, the
* SkCodec takes ownership of it, and will delete it when done with it.
*/
static std::unique_ptr<SkCodec> MakeFromStream(std::unique_ptr<SkStream>, Result* = nullptr,
SkPngChunkReader* = nullptr);
/**
* If this data represents an encoded image that we know how to decode,
* return an SkCodec that can decode it. Otherwise return NULL.
*
* If the SkPngChunkReader is not NULL then:
* If the image is not a PNG, the SkPngChunkReader will be ignored.
* If the image is a PNG, the SkPngChunkReader will be reffed.
* If the PNG has unknown chunks, the SkPngChunkReader will be used
* to handle these chunks. SkPngChunkReader will be called to read
* any unknown chunk at any point during the creation of the codec
* or the decode. Note that if SkPngChunkReader fails to read a
* chunk, this could result in a failure to create the codec or a
* failure to decode the image.
* If the PNG does not contain unknown chunks, the SkPngChunkReader
* will not be used or modified.
*/
static std::unique_ptr<SkCodec> MakeFromData(sk_sp<SkData>, SkPngChunkReader* = nullptr);
virtual ~SkCodec();
/**
* Return a reasonable SkImageInfo to decode into.
*/
SkImageInfo getInfo() const { return fEncodedInfo.makeImageInfo(); }
SkISize dimensions() const { return {fEncodedInfo.width(), fEncodedInfo.height()}; }
SkIRect bounds() const {
return SkIRect::MakeWH(fEncodedInfo.width(), fEncodedInfo.height());
}
/**
* Returns the image orientation stored in the EXIF data.
* If there is no EXIF data, or if we cannot read the EXIF data, returns kTopLeft.
*/
SkEncodedOrigin getOrigin() const { return fOrigin; }
/**
* Return a size that approximately supports the desired scale factor.
* The codec may not be able to scale efficiently to the exact scale
* factor requested, so return a size that approximates that scale.
* The returned value is the codec's suggestion for the closest valid
* scale that it can natively support
*/
SkISize getScaledDimensions(float desiredScale) const {
// Negative and zero scales are errors.
SkASSERT(desiredScale > 0.0f);
if (desiredScale <= 0.0f) {
return SkISize::Make(0, 0);
}
// Upscaling is not supported. Return the original size if the client
// requests an upscale.
if (desiredScale >= 1.0f) {
return this->dimensions();
}
return this->onGetScaledDimensions(desiredScale);
}
/**
* Return (via desiredSubset) a subset which can decoded from this codec,
* or false if this codec cannot decode subsets or anything similar to
* desiredSubset.
*
* @param desiredSubset In/out parameter. As input, a desired subset of
* the original bounds (as specified by getInfo). If true is returned,
* desiredSubset may have been modified to a subset which is
* supported. Although a particular change may have been made to
* desiredSubset to create something supported, it is possible other
* changes could result in a valid subset.
* If false is returned, desiredSubset's value is undefined.
* @return true if this codec supports decoding desiredSubset (as
* returned, potentially modified)
*/
bool getValidSubset(SkIRect* desiredSubset) const {
return this->onGetValidSubset(desiredSubset);
}
/**
* Format of the encoded data.
*/
SkEncodedImageFormat getEncodedFormat() const { return this->onGetEncodedFormat(); }
/**
* Whether or not the memory passed to getPixels is zero initialized.
*/
enum ZeroInitialized {
/**
* The memory passed to getPixels is zero initialized. The SkCodec
* may take advantage of this by skipping writing zeroes.
*/
kYes_ZeroInitialized,
/**
* The memory passed to getPixels has not been initialized to zero,
* so the SkCodec must write all zeroes to memory.
*
* This is the default. It will be used if no Options struct is used.
*/
kNo_ZeroInitialized,
};
/**
* Additional options to pass to getPixels.
*/
struct Options {
Options()
: fZeroInitialized(kNo_ZeroInitialized)
Add support for multiple frames in SkCodec 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
2016-10-24 16:03:26 +00:00
, fSubset(nullptr)
, fFrameIndex(0)
, fPriorFrame(kNoFrame)
{}
ZeroInitialized fZeroInitialized;
/**
* If not NULL, represents a subset of the original image to decode.
* Must be within the bounds returned by getInfo().
* If the EncodedFormat is SkEncodedImageFormat::kWEBP (the only one which
* currently supports subsets), the top and left values must be even.
*
Make SkPngCodec decode progressively. This is a step towards using SkCodec in Chromium, where progressive decoding is necessary. Switch from using png_read_row (which expects all the data to be available) to png_process_data, which uses callbacks when rows are available. Create a new API for SkCodec, which supports progressive decoding and scanline decoding. Future changes will switch the other clients off of startScanlineDecode and get/skip-Scanlines to the new API. Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced PNG images. In the new API, interlaced PNG fits kTopDown. Also remove updateCurrScanline(), which was only used by the old implementation for interlaced PNG. DMSrcSink: - In CodecSrc::kScanline_Mode, use the new method for scanline decoding for the supported formats (just PNG and PNG-in-ICO for now). fuzz.cpp: - Remove reference to kNone_ScanlineOrder SkCodec: - Add new APIs: - startIncrementalDecode - incrementalDecode - Remove kNone_SkScanlineOrder and updateCurrScanline() - Set fDstInfo and fOptions in getPixels(). This may not be necessary for all implementations, but it simplifies things for SkPngCodec. SkPngCodec: - Implement new APIs - Switch from sk_read_fn/png_read_row etc to png_process_data - Expand AutoCleanPng's role to decode the header and create the SkPngCodec - Make the interlaced PNG decoder report how many lines were initialized during an incomplete decode SkIcoCodec: - Implement the new APIs; supported for PNG in ICO SkSampledCodec: - Call the new method for decoding scanlines, and fall back to the old method if the new version is unimplemented - Remove references to kNone_SkScanlineOrder tests/CodecPartial: - Add a test which decodes part of an image, then finishes the decode, and compares it to the straightforward method tests/CodecTest: - Add a test which decodes all scanlines using the new method - Repurpose the Codec_stripes test to decode using the new method in sections rather than all at once - In the method check(), add a parameter for whether the image supports the new method of scanline decoding, and be explicit about whether an image supports incomplete - Test incomplete PNG decodes. We should have been doing it anyway for non-interlaced (except for an image that is too small - one row), but the new method supports interlaced incomplete as well - Make test_invalid_parameters test the new method - Add a test to ensure that it's safe to fall back to scanline decoding without rewinding BUG=skia:4211 The new version was generally faster than the old version (but not significantly so). Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/ Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/ GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003 Review-Url: https://codereview.chromium.org/1997703003
2016-09-16 15:20:38 +00:00
* In getPixels and incremental decode, we will attempt to decode the
* exact rectangular subset specified by fSubset.
*
* In a scanline decode, it does not make sense to specify a subset
* top or subset height, since the client already controls which rows
* to get and which rows to skip. During scanline decodes, we will
* require that the subset top be zero and the subset height be equal
* to the full height. We will, however, use the values of
* subset left and subset width to decode partial scanlines on calls
* to getScanlines().
*/
const SkIRect* fSubset;
Add support for multiple frames in SkCodec 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
2016-10-24 16:03:26 +00:00
/**
* The frame to decode.
*
* Only meaningful for multi-frame images.
*/
int fFrameIndex;
Add support for multiple frames in SkCodec 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
2016-10-24 16:03:26 +00:00
/**
* If not kNoFrame, the dst already contains the prior frame at this index.
Add support for multiple frames in SkCodec 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
2016-10-24 16:03:26 +00:00
*
* Only meaningful for multi-frame images.
*
* If fFrameIndex needs to be blended with a prior frame (as reported by
* getFrameInfo[fFrameIndex].fRequiredFrame), the client can set this to
* any non-kRestorePrevious frame in [fRequiredFrame, fFrameIndex) to
* indicate that that frame is already in the dst. Options.fZeroInitialized
* is ignored in this case.
Add support for multiple frames in SkCodec 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
2016-10-24 16:03:26 +00:00
*
* If set to kNoFrame, the codec will decode any necessary required frame(s) first.
Add support for multiple frames in SkCodec 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
2016-10-24 16:03:26 +00:00
*/
int fPriorFrame;
};
/**
* Decode into the given pixels, a block of memory of size at
* least (info.fHeight - 1) * rowBytes + (info.fWidth *
* bytesPerPixel)
*
* Repeated calls to this function should give the same results,
* allowing the PixelRef to be immutable.
*
* @param info A description of the format (config, size)
* expected by the caller. This can simply be identical
* to the info returned by getInfo().
*
* This contract also allows the caller to specify
* different output-configs, which the implementation can
* decide to support or not.
*
* A size that does not match getInfo() implies a request
* to scale. If the generator cannot perform this scale,
* it will return kInvalidScale.
*
* If the info contains a non-null SkColorSpace, the codec
* will perform the appropriate color space transformation.
* If the caller passes in the same color space that was
* reported by the codec, the color space transformation is
* a no-op.
*
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
* If a scanline decode is in progress, scanline mode will end, requiring the client to call
* startScanlineDecode() in order to return to decoding scanlines.
*
* @return Result kSuccess, or another value explaining the type of failure.
*/
Result getPixels(const SkImageInfo& info, void* pixels, size_t rowBytes, const Options*);
/**
* Simplified version of getPixels() that uses the default Options.
*/
Result getPixels(const SkImageInfo& info, void* pixels, size_t rowBytes) {
return this->getPixels(info, pixels, rowBytes, nullptr);
}
Revert[4] "apply codec origin in generator" This reverts commit dd340146f1fe7414702d6fea251da989d425691e. Reason for revert: ios gn file fixed Original change's description: > Revert "Revert "Revert "apply codec origin in generator""" > > This reverts commit 82269abfec798621c8dbbc6bd48996c0b2686f41. > > Reason for revert: ios build needs include path for SkCodec.h > > Original change's description: > > Revert "Revert "apply codec origin in generator"" > > > > This reverts commit 363dd988a55c2ed3fa92e2368c1c889101425734. > > > > Reason for revert: pdfium fix landed > > > > Original change's description: > > > Revert "apply codec origin in generator" > > > > > > This reverts commit fa15877f487333bec876e7315cf584c0d598d098. > > > > > > Reason for revert: Appears to break PDFium. > > > > > > Original change's description: > > > > apply codec origin in generator > > > > > > > > Bug: skia: > > > > Change-Id: I383dacb49b1e3c88467ccdbf3288764bb1bbf01a > > > > Reviewed-on: https://skia-review.googlesource.com/58600 > > > > Reviewed-by: Leon Scroggins <scroggo@google.com> > > > > Commit-Queue: Mike Reed <reed@google.com> > > > > > > TBR=scroggo@google.com,reed@google.com > > > > > > Change-Id: Id97137d6ec39ca638c941928bae6510814b1c499 > > > No-Presubmit: true > > > No-Tree-Checks: true > > > No-Try: true > > > Bug: skia: > > > Reviewed-on: https://skia-review.googlesource.com/60041 > > > Reviewed-by: Ben Wagner <benjaminwagner@google.com> > > > Commit-Queue: Ben Wagner <benjaminwagner@google.com> > > > > TBR=benjaminwagner@google.com,scroggo@google.com,reed@google.com > > > > Change-Id: I1b54a6e6e6cbda07f346ffbbc4977f9db705abcd > > No-Presubmit: true > > No-Tree-Checks: true > > No-Try: true > > Bug: skia: > > Reviewed-on: https://skia-review.googlesource.com/60320 > > Reviewed-by: Mike Reed <reed@google.com> > > Commit-Queue: Mike Reed <reed@google.com> > > TBR=benjaminwagner@google.com,scroggo@google.com,reed@google.com > > Change-Id: I4c2d310521d1a678b407d30b9fe3c261c49d67bc > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: skia: > Reviewed-on: https://skia-review.googlesource.com/60560 > Reviewed-by: Mike Reed <reed@google.com> > Commit-Queue: Mike Reed <reed@google.com> TBR=benjaminwagner@google.com,scroggo@google.com,reed@google.com Change-Id: I5c1e53aff3ad174b0d4a806c35b7cdcd194479d7 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: skia: Reviewed-on: https://skia-review.googlesource.com/60563 Reviewed-by: Mike Reed <reed@google.com> Commit-Queue: Mike Reed <reed@google.com>
2017-10-17 18:04:32 +00:00
Result getPixels(const SkPixmap& pm, const Options* opts = nullptr) {
return this->getPixels(pm.info(), pm.writable_addr(), pm.rowBytes(), opts);
}
/**
* If decoding to YUV is supported, this returns true. Otherwise, this
* returns false and does not modify any of the parameters.
*
* @param sizeInfo Output parameter indicating the sizes and required
* allocation widths of the Y, U, V, and A planes. Given current codec
* limitations the size of the A plane will always be 0 and the Y, U, V
* channels will always be planar.
* @param colorSpace Output parameter. If non-NULL this is set to kJPEG,
* otherwise this is ignored.
*/
bool queryYUV8(SkYUVASizeInfo* sizeInfo, SkYUVColorSpace* colorSpace) const {
if (nullptr == sizeInfo) {
return false;
}
bool result = this->onQueryYUV8(sizeInfo, colorSpace);
if (result) {
for (int i = 0; i <= 2; ++i) {
SkASSERT(sizeInfo->fSizes[i].fWidth > 0 && sizeInfo->fSizes[i].fHeight > 0 &&
sizeInfo->fWidthBytes[i] > 0);
}
SkASSERT(!sizeInfo->fSizes[3].fWidth &&
!sizeInfo->fSizes[3].fHeight &&
!sizeInfo->fWidthBytes[3]);
}
return result;
}
/**
* Returns kSuccess, or another value explaining the type of failure.
* This always attempts to perform a full decode. If the client only
* wants size, it should call queryYUV8().
*
* @param sizeInfo Needs to exactly match the values returned by the
* query, except the WidthBytes may be larger than the
* recommendation (but not smaller).
* @param planes Memory for each of the Y, U, and V planes.
*/
Result getYUV8Planes(const SkYUVASizeInfo& sizeInfo, void* planes[SkYUVASizeInfo::kMaxCount]) {
if (!planes || !planes[0] || !planes[1] || !planes[2]) {
return kInvalidInput;
}
SkASSERT(!planes[3]); // TODO: is this a fair assumption?
if (!this->rewindIfNeeded()) {
return kCouldNotRewind;
}
return this->onGetYUV8Planes(sizeInfo, planes);
}
Make SkPngCodec decode progressively. This is a step towards using SkCodec in Chromium, where progressive decoding is necessary. Switch from using png_read_row (which expects all the data to be available) to png_process_data, which uses callbacks when rows are available. Create a new API for SkCodec, which supports progressive decoding and scanline decoding. Future changes will switch the other clients off of startScanlineDecode and get/skip-Scanlines to the new API. Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced PNG images. In the new API, interlaced PNG fits kTopDown. Also remove updateCurrScanline(), which was only used by the old implementation for interlaced PNG. DMSrcSink: - In CodecSrc::kScanline_Mode, use the new method for scanline decoding for the supported formats (just PNG and PNG-in-ICO for now). fuzz.cpp: - Remove reference to kNone_ScanlineOrder SkCodec: - Add new APIs: - startIncrementalDecode - incrementalDecode - Remove kNone_SkScanlineOrder and updateCurrScanline() - Set fDstInfo and fOptions in getPixels(). This may not be necessary for all implementations, but it simplifies things for SkPngCodec. SkPngCodec: - Implement new APIs - Switch from sk_read_fn/png_read_row etc to png_process_data - Expand AutoCleanPng's role to decode the header and create the SkPngCodec - Make the interlaced PNG decoder report how many lines were initialized during an incomplete decode SkIcoCodec: - Implement the new APIs; supported for PNG in ICO SkSampledCodec: - Call the new method for decoding scanlines, and fall back to the old method if the new version is unimplemented - Remove references to kNone_SkScanlineOrder tests/CodecPartial: - Add a test which decodes part of an image, then finishes the decode, and compares it to the straightforward method tests/CodecTest: - Add a test which decodes all scanlines using the new method - Repurpose the Codec_stripes test to decode using the new method in sections rather than all at once - In the method check(), add a parameter for whether the image supports the new method of scanline decoding, and be explicit about whether an image supports incomplete - Test incomplete PNG decodes. We should have been doing it anyway for non-interlaced (except for an image that is too small - one row), but the new method supports interlaced incomplete as well - Make test_invalid_parameters test the new method - Add a test to ensure that it's safe to fall back to scanline decoding without rewinding BUG=skia:4211 The new version was generally faster than the old version (but not significantly so). Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/ Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/ GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003 Review-Url: https://codereview.chromium.org/1997703003
2016-09-16 15:20:38 +00:00
/**
* Prepare for an incremental decode with the specified options.
*
* This may require a rewind.
*
* If kIncompleteInput is returned, may be called again after more data has
* been provided to the source SkStream.
*
Make SkPngCodec decode progressively. This is a step towards using SkCodec in Chromium, where progressive decoding is necessary. Switch from using png_read_row (which expects all the data to be available) to png_process_data, which uses callbacks when rows are available. Create a new API for SkCodec, which supports progressive decoding and scanline decoding. Future changes will switch the other clients off of startScanlineDecode and get/skip-Scanlines to the new API. Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced PNG images. In the new API, interlaced PNG fits kTopDown. Also remove updateCurrScanline(), which was only used by the old implementation for interlaced PNG. DMSrcSink: - In CodecSrc::kScanline_Mode, use the new method for scanline decoding for the supported formats (just PNG and PNG-in-ICO for now). fuzz.cpp: - Remove reference to kNone_ScanlineOrder SkCodec: - Add new APIs: - startIncrementalDecode - incrementalDecode - Remove kNone_SkScanlineOrder and updateCurrScanline() - Set fDstInfo and fOptions in getPixels(). This may not be necessary for all implementations, but it simplifies things for SkPngCodec. SkPngCodec: - Implement new APIs - Switch from sk_read_fn/png_read_row etc to png_process_data - Expand AutoCleanPng's role to decode the header and create the SkPngCodec - Make the interlaced PNG decoder report how many lines were initialized during an incomplete decode SkIcoCodec: - Implement the new APIs; supported for PNG in ICO SkSampledCodec: - Call the new method for decoding scanlines, and fall back to the old method if the new version is unimplemented - Remove references to kNone_SkScanlineOrder tests/CodecPartial: - Add a test which decodes part of an image, then finishes the decode, and compares it to the straightforward method tests/CodecTest: - Add a test which decodes all scanlines using the new method - Repurpose the Codec_stripes test to decode using the new method in sections rather than all at once - In the method check(), add a parameter for whether the image supports the new method of scanline decoding, and be explicit about whether an image supports incomplete - Test incomplete PNG decodes. We should have been doing it anyway for non-interlaced (except for an image that is too small - one row), but the new method supports interlaced incomplete as well - Make test_invalid_parameters test the new method - Add a test to ensure that it's safe to fall back to scanline decoding without rewinding BUG=skia:4211 The new version was generally faster than the old version (but not significantly so). Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/ Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/ GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003 Review-Url: https://codereview.chromium.org/1997703003
2016-09-16 15:20:38 +00:00
* @param dstInfo Info of the destination. If the dimensions do not match
* those of getInfo, this implies a scale.
* @param dst Memory to write to. Needs to be large enough to hold the subset,
* if present, or the full image as described in dstInfo.
* @param options Contains decoding options, including if memory is zero
* initialized and whether to decode a subset.
* @return Enum representing success or reason for failure.
*/
Result startIncrementalDecode(const SkImageInfo& dstInfo, void* dst, size_t rowBytes,
const Options*);
Make SkPngCodec decode progressively. This is a step towards using SkCodec in Chromium, where progressive decoding is necessary. Switch from using png_read_row (which expects all the data to be available) to png_process_data, which uses callbacks when rows are available. Create a new API for SkCodec, which supports progressive decoding and scanline decoding. Future changes will switch the other clients off of startScanlineDecode and get/skip-Scanlines to the new API. Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced PNG images. In the new API, interlaced PNG fits kTopDown. Also remove updateCurrScanline(), which was only used by the old implementation for interlaced PNG. DMSrcSink: - In CodecSrc::kScanline_Mode, use the new method for scanline decoding for the supported formats (just PNG and PNG-in-ICO for now). fuzz.cpp: - Remove reference to kNone_ScanlineOrder SkCodec: - Add new APIs: - startIncrementalDecode - incrementalDecode - Remove kNone_SkScanlineOrder and updateCurrScanline() - Set fDstInfo and fOptions in getPixels(). This may not be necessary for all implementations, but it simplifies things for SkPngCodec. SkPngCodec: - Implement new APIs - Switch from sk_read_fn/png_read_row etc to png_process_data - Expand AutoCleanPng's role to decode the header and create the SkPngCodec - Make the interlaced PNG decoder report how many lines were initialized during an incomplete decode SkIcoCodec: - Implement the new APIs; supported for PNG in ICO SkSampledCodec: - Call the new method for decoding scanlines, and fall back to the old method if the new version is unimplemented - Remove references to kNone_SkScanlineOrder tests/CodecPartial: - Add a test which decodes part of an image, then finishes the decode, and compares it to the straightforward method tests/CodecTest: - Add a test which decodes all scanlines using the new method - Repurpose the Codec_stripes test to decode using the new method in sections rather than all at once - In the method check(), add a parameter for whether the image supports the new method of scanline decoding, and be explicit about whether an image supports incomplete - Test incomplete PNG decodes. We should have been doing it anyway for non-interlaced (except for an image that is too small - one row), but the new method supports interlaced incomplete as well - Make test_invalid_parameters test the new method - Add a test to ensure that it's safe to fall back to scanline decoding without rewinding BUG=skia:4211 The new version was generally faster than the old version (but not significantly so). Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/ Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/ GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003 Review-Url: https://codereview.chromium.org/1997703003
2016-09-16 15:20:38 +00:00
Result startIncrementalDecode(const SkImageInfo& dstInfo, void* dst, size_t rowBytes) {
return this->startIncrementalDecode(dstInfo, dst, rowBytes, nullptr);
Make SkPngCodec decode progressively. This is a step towards using SkCodec in Chromium, where progressive decoding is necessary. Switch from using png_read_row (which expects all the data to be available) to png_process_data, which uses callbacks when rows are available. Create a new API for SkCodec, which supports progressive decoding and scanline decoding. Future changes will switch the other clients off of startScanlineDecode and get/skip-Scanlines to the new API. Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced PNG images. In the new API, interlaced PNG fits kTopDown. Also remove updateCurrScanline(), which was only used by the old implementation for interlaced PNG. DMSrcSink: - In CodecSrc::kScanline_Mode, use the new method for scanline decoding for the supported formats (just PNG and PNG-in-ICO for now). fuzz.cpp: - Remove reference to kNone_ScanlineOrder SkCodec: - Add new APIs: - startIncrementalDecode - incrementalDecode - Remove kNone_SkScanlineOrder and updateCurrScanline() - Set fDstInfo and fOptions in getPixels(). This may not be necessary for all implementations, but it simplifies things for SkPngCodec. SkPngCodec: - Implement new APIs - Switch from sk_read_fn/png_read_row etc to png_process_data - Expand AutoCleanPng's role to decode the header and create the SkPngCodec - Make the interlaced PNG decoder report how many lines were initialized during an incomplete decode SkIcoCodec: - Implement the new APIs; supported for PNG in ICO SkSampledCodec: - Call the new method for decoding scanlines, and fall back to the old method if the new version is unimplemented - Remove references to kNone_SkScanlineOrder tests/CodecPartial: - Add a test which decodes part of an image, then finishes the decode, and compares it to the straightforward method tests/CodecTest: - Add a test which decodes all scanlines using the new method - Repurpose the Codec_stripes test to decode using the new method in sections rather than all at once - In the method check(), add a parameter for whether the image supports the new method of scanline decoding, and be explicit about whether an image supports incomplete - Test incomplete PNG decodes. We should have been doing it anyway for non-interlaced (except for an image that is too small - one row), but the new method supports interlaced incomplete as well - Make test_invalid_parameters test the new method - Add a test to ensure that it's safe to fall back to scanline decoding without rewinding BUG=skia:4211 The new version was generally faster than the old version (but not significantly so). Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/ Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/ GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003 Review-Url: https://codereview.chromium.org/1997703003
2016-09-16 15:20:38 +00:00
}
/**
* Start/continue the incremental decode.
*
* Not valid to call before a call to startIncrementalDecode() returns
* kSuccess.
Make SkPngCodec decode progressively. This is a step towards using SkCodec in Chromium, where progressive decoding is necessary. Switch from using png_read_row (which expects all the data to be available) to png_process_data, which uses callbacks when rows are available. Create a new API for SkCodec, which supports progressive decoding and scanline decoding. Future changes will switch the other clients off of startScanlineDecode and get/skip-Scanlines to the new API. Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced PNG images. In the new API, interlaced PNG fits kTopDown. Also remove updateCurrScanline(), which was only used by the old implementation for interlaced PNG. DMSrcSink: - In CodecSrc::kScanline_Mode, use the new method for scanline decoding for the supported formats (just PNG and PNG-in-ICO for now). fuzz.cpp: - Remove reference to kNone_ScanlineOrder SkCodec: - Add new APIs: - startIncrementalDecode - incrementalDecode - Remove kNone_SkScanlineOrder and updateCurrScanline() - Set fDstInfo and fOptions in getPixels(). This may not be necessary for all implementations, but it simplifies things for SkPngCodec. SkPngCodec: - Implement new APIs - Switch from sk_read_fn/png_read_row etc to png_process_data - Expand AutoCleanPng's role to decode the header and create the SkPngCodec - Make the interlaced PNG decoder report how many lines were initialized during an incomplete decode SkIcoCodec: - Implement the new APIs; supported for PNG in ICO SkSampledCodec: - Call the new method for decoding scanlines, and fall back to the old method if the new version is unimplemented - Remove references to kNone_SkScanlineOrder tests/CodecPartial: - Add a test which decodes part of an image, then finishes the decode, and compares it to the straightforward method tests/CodecTest: - Add a test which decodes all scanlines using the new method - Repurpose the Codec_stripes test to decode using the new method in sections rather than all at once - In the method check(), add a parameter for whether the image supports the new method of scanline decoding, and be explicit about whether an image supports incomplete - Test incomplete PNG decodes. We should have been doing it anyway for non-interlaced (except for an image that is too small - one row), but the new method supports interlaced incomplete as well - Make test_invalid_parameters test the new method - Add a test to ensure that it's safe to fall back to scanline decoding without rewinding BUG=skia:4211 The new version was generally faster than the old version (but not significantly so). Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/ Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/ GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003 Review-Url: https://codereview.chromium.org/1997703003
2016-09-16 15:20:38 +00:00
*
* If kIncompleteInput is returned, may be called again after more data has
* been provided to the source SkStream.
Make SkPngCodec decode progressively. This is a step towards using SkCodec in Chromium, where progressive decoding is necessary. Switch from using png_read_row (which expects all the data to be available) to png_process_data, which uses callbacks when rows are available. Create a new API for SkCodec, which supports progressive decoding and scanline decoding. Future changes will switch the other clients off of startScanlineDecode and get/skip-Scanlines to the new API. Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced PNG images. In the new API, interlaced PNG fits kTopDown. Also remove updateCurrScanline(), which was only used by the old implementation for interlaced PNG. DMSrcSink: - In CodecSrc::kScanline_Mode, use the new method for scanline decoding for the supported formats (just PNG and PNG-in-ICO for now). fuzz.cpp: - Remove reference to kNone_ScanlineOrder SkCodec: - Add new APIs: - startIncrementalDecode - incrementalDecode - Remove kNone_SkScanlineOrder and updateCurrScanline() - Set fDstInfo and fOptions in getPixels(). This may not be necessary for all implementations, but it simplifies things for SkPngCodec. SkPngCodec: - Implement new APIs - Switch from sk_read_fn/png_read_row etc to png_process_data - Expand AutoCleanPng's role to decode the header and create the SkPngCodec - Make the interlaced PNG decoder report how many lines were initialized during an incomplete decode SkIcoCodec: - Implement the new APIs; supported for PNG in ICO SkSampledCodec: - Call the new method for decoding scanlines, and fall back to the old method if the new version is unimplemented - Remove references to kNone_SkScanlineOrder tests/CodecPartial: - Add a test which decodes part of an image, then finishes the decode, and compares it to the straightforward method tests/CodecTest: - Add a test which decodes all scanlines using the new method - Repurpose the Codec_stripes test to decode using the new method in sections rather than all at once - In the method check(), add a parameter for whether the image supports the new method of scanline decoding, and be explicit about whether an image supports incomplete - Test incomplete PNG decodes. We should have been doing it anyway for non-interlaced (except for an image that is too small - one row), but the new method supports interlaced incomplete as well - Make test_invalid_parameters test the new method - Add a test to ensure that it's safe to fall back to scanline decoding without rewinding BUG=skia:4211 The new version was generally faster than the old version (but not significantly so). Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/ Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/ GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003 Review-Url: https://codereview.chromium.org/1997703003
2016-09-16 15:20:38 +00:00
*
* Unlike getPixels and getScanlines, this does not do any filling. This is
* left up to the caller, since they may be skipping lines or continuing the
* decode later. In the latter case, they may choose to initialize all lines
* first, or only initialize the remaining lines after the first call.
*
* @param rowsDecoded Optional output variable returning the total number of
* lines initialized. Only meaningful if this method returns kIncompleteInput.
* Otherwise the implementation may not set it.
* Note that some implementations may have initialized this many rows, but
* not necessarily finished those rows (e.g. interlaced PNG). This may be
* useful for determining what rows the client needs to initialize.
* @return kSuccess if all lines requested in startIncrementalDecode have
* been completely decoded. kIncompleteInput otherwise.
*/
Result incrementalDecode(int* rowsDecoded = nullptr) {
if (!fStartedIncrementalDecode) {
return kInvalidParameters;
}
return this->onIncrementalDecode(rowsDecoded);
}
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
/**
* The remaining functions revolve around decoding scanlines.
*/
/**
* Prepare for a scanline decode with the specified options.
*
* After this call, this class will be ready to decode the first scanline.
*
* This must be called in order to call getScanlines or skipScanlines.
*
* This may require rewinding the stream.
*
* Not all SkCodecs support this.
*
* @param dstInfo Info of the destination. If the dimensions do not match
* those of getInfo, this implies a scale.
* @param options Contains decoding options, including if memory is zero
* initialized.
* @return Enum representing success or reason for failure.
*/
Result startScanlineDecode(const SkImageInfo& dstInfo, const Options* options);
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
/**
* Simplified version of startScanlineDecode() that uses the default Options.
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
*/
Result startScanlineDecode(const SkImageInfo& dstInfo) {
return this->startScanlineDecode(dstInfo, nullptr);
}
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
/**
* Write the next countLines scanlines into dst.
*
* Not valid to call before calling startScanlineDecode().
*
* @param dst Must be non-null, and large enough to hold countLines
* scanlines of size rowBytes.
* @param countLines Number of lines to write.
* @param rowBytes Number of bytes per row. Must be large enough to hold
* a scanline based on the SkImageInfo used to create this object.
* @return the number of lines successfully decoded. If this value is
* less than countLines, this will fill the remaining lines with a
* default value.
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
*/
int getScanlines(void* dst, int countLines, size_t rowBytes);
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
/**
* Skip count scanlines.
*
* Not valid to call before calling startScanlineDecode().
*
* The default version just calls onGetScanlines and discards the dst.
* NOTE: If skipped lines are the only lines with alpha, this default
* will make reallyHasAlpha return true, when it could have returned
* false.
*
* @return true if the scanlines were successfully skipped
* false on failure, possible reasons for failure include:
* An incomplete input image stream.
* Calling this function before calling startScanlineDecode().
* If countLines is less than zero or so large that it moves
* the current scanline past the end of the image.
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
*/
bool skipScanlines(int countLines);
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
/**
* The order in which rows are output from the scanline decoder is not the
* same for all variations of all image types. This explains the possible
* output row orderings.
*/
enum SkScanlineOrder {
/*
* By far the most common, this indicates that the image can be decoded
* reliably using the scanline decoder, and that rows will be output in
* the logical order.
*/
kTopDown_SkScanlineOrder,
/*
* This indicates that the scanline decoder reliably outputs rows, but
* they will be returned in reverse order. If the scanline format is
* kBottomUp, the nextScanline() API can be used to determine the actual
* y-coordinate of the next output row, but the client is not forced
* to take advantage of this, given that it's not too tough to keep
* track independently.
*
* For full image decodes, it is safe to get all of the scanlines at
* once, since the decoder will handle inverting the rows as it
* decodes.
*
* For subset decodes and sampling, it is simplest to get and skip
* scanlines one at a time, using the nextScanline() API. It is
* possible to ask for larger chunks at a time, but this should be used
* with caution. As with full image decodes, the decoder will handle
* inverting the requested rows, but rows will still be delivered
* starting from the bottom of the image.
*
* Upside down bmps are an example.
*/
kBottomUp_SkScanlineOrder,
};
/**
* An enum representing the order in which scanlines will be returned by
* the scanline decoder.
*
* This is undefined before startScanlineDecode() is called.
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
*/
SkScanlineOrder getScanlineOrder() const { return this->onGetScanlineOrder(); }
/**
* Returns the y-coordinate of the next row to be returned by the scanline
* decoder.
*
* This will equal fCurrScanline, except in the case of strangely
Add support for multiple frames in SkCodec 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
2016-10-24 16:03:26 +00:00
* encoded image types (bottom-up bmps).
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
*
* Results are undefined when not in scanline decoding mode.
*/
int nextScanline() const { return this->outputScanline(fCurrScanline); }
/**
* Returns the output y-coordinate of the row that corresponds to an input
* y-coordinate. The input y-coordinate represents where the scanline
* is located in the encoded data.
*
* This will equal inputScanline, except in the case of strangely
* encoded image types (bottom-up bmps, interlaced gifs).
*/
int outputScanline(int inputScanline) const;
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
/**
* Return the number of frames in the image.
*
* May require reading through the stream.
*/
int getFrameCount() {
return this->onGetFrameCount();
}
// Sentinel value used when a frame index implies "no frame":
// - FrameInfo::fRequiredFrame set to this value means the frame
// is independent.
// - Options::fPriorFrame set to this value means no (relevant) prior frame
// is residing in dst's memory.
static constexpr int kNoFrame = -1;
// This transitional definition was added in August 2018, and will eventually be removed.
#ifdef SK_LEGACY_SKCODEC_NONE_ENUM
static constexpr int kNone = kNoFrame;
#endif
Add support for multiple frames in SkCodec 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
2016-10-24 16:03:26 +00:00
/**
* Information about individual frames in a multi-framed image.
*/
struct FrameInfo {
/**
* The frame that this frame needs to be blended with, or
* kNoFrame if this frame is independent.
*
* Note that this is the *earliest* frame that can be used
* for blending. Any frame from [fRequiredFrame, i) can be
* used, unless its fDisposalMethod is kRestorePrevious.
Add support for multiple frames in SkCodec 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
2016-10-24 16:03:26 +00:00
*/
int fRequiredFrame;
Add support for multiple frames in SkCodec 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
2016-10-24 16:03:26 +00:00
/**
* Number of milliseconds to show this frame.
*/
int fDuration;
/**
* Whether the end marker for this frame is contained in the stream.
*
* Note: this does not guarantee that an attempt to decode will be complete.
* There could be an error in the stream.
*/
bool fFullyReceived;
/**
* This is conservative; it will still return non-opaque if e.g. a
* color index-based frame has a color with alpha but does not use it.
*/
SkAlphaType fAlphaType;
/**
* How this frame should be modified before decoding the next one.
*/
SkCodecAnimation::DisposalMethod fDisposalMethod;
Add support for multiple frames in SkCodec 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
2016-10-24 16:03:26 +00:00
};
/**
* Return info about a single frame.
*
* Only supported by multi-frame images. Does not read through the stream,
* so it should be called after getFrameCount() to parse any frames that
* have not already been parsed.
*/
bool getFrameInfo(int index, FrameInfo* info) const {
Add animation support to SkWebpCodec TBR=reed@google.com (No change to the public API, but changed a header file) SkWebpCodec: - Implement onGetFrameCount, onGetFrameInfo, and onGetRepetitionCount - Respect the alpha reported by libwebp. Although the spec states that it is only a hint, the libwebp encoder uses it properly. Respecting allows us to draw opaque images faster and decode them to 565. This also matches other SkCodecs (and Chromium). - onGetPixels: - Decode the frame requested, recursively decoding required frame if necessary - When blending with a prior frame, use SkRasterPipeline SkCodec: - Move check for negative index to getFrameInfo - Reset the colorXform if one is not needed SkCodecAnimation: - Add new blend enum, for WebP's (and APNG's) non-blending option SkFrameHolder: - New base classes for frames and the owner of the frames, allowing code sharing between SkWebpCodec and SkGifCodec (particularly for determining whether a frame has alpha and what frame it depends on) - When moving items from SkGIFFrameContext, use Skia conventions (i.e. int instead of unsigned) - Rename "delay time" to "duration", to match e.g. SkFrameInfo:: fDuration SkGifImageReader: - Move pieces to SkFrameHolder, and adapt to changes made in the process - Make setAlphaAndRequiredFrame (now on the base class SkFrameHolder) more general to support webp, and add support for frames that do not blend - Change SkGIFFrameContext from a struct to a class, to match how we use the distinction elsewhere (i.e. struct is a small object with public fields) - Rework hasTransparentPixel (now hasTransparency, since it returns true in some cases where there is not a transparent pixel) to better fit with the modified setAlphaAndRequiredFrame. Also be more consistent when there is no transparent pixel but no color map. - Simplify an if condition that was previously simplified in 2d61e717 but accidentally got reverted in a4db9be6 CodecAnimTest: - Test new animated webp files - Rearrange the test to more cleanly print alpha type mismatches for the first frame resources: - webp-animated.webp - animated webp from Chromium - blendBG.webp - new webp file using bits of webp-animated-semitransparent4.webp from Chromium - tests required frame and alpha when using the non-blending mode - frames have the following properties: - Frame 0: no alpha, fills screen - Frame 1: alpha, fills screen - Frame 2: no alpha, fills screen - Frame 3: alpha, fills screen, blendBG - Frame 4: no alpha, fills screen, blendBG - Frame 5: alpha, blendBG - Frame 6: covers 4, has alpha, blendBG - also used to test decoding to 565 if the new frame data has alpha but blends onto an opaque frame DM.cpp: - Test animated images to non-native 8888 and unpremul DMSrcSink.cpp: - Do not test non-native 8888 decodes to f16 dst - Test unpremul decodes to f16 - Copy a frame of an animated image prior to drawing, since in unpremul mode, the DM code will premultiply first. Bug: skia: 3315 Change-Id: I4e55ae2ee5bc095b37a743bdcfac644be603b980 Reviewed-on: https://skia-review.googlesource.com/16707 Commit-Queue: Mike Reed <reed@google.com> Reviewed-by: Mike Reed <reed@google.com> Reviewed-by: Leon Scroggins <scroggo@google.com> Reviewed-by: Matt Sarett <msarett@google.com>
2017-05-23 13:37:21 +00:00
if (index < 0) {
return false;
}
return this->onGetFrameInfo(index, info);
}
/**
* Return info about all the frames in the image.
Add support for multiple frames in SkCodec 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
2016-10-24 16:03:26 +00:00
*
* May require reading through the stream to determine info about the
* frames (including the count).
Add support for multiple frames in SkCodec 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
2016-10-24 16:03:26 +00:00
*
* As such, future decoding calls may require a rewind.
*
* For still (non-animated) image codecs, this will return an empty vector.
Add support for multiple frames in SkCodec 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
2016-10-24 16:03:26 +00:00
*/
std::vector<FrameInfo> getFrameInfo();
Add support for multiple frames in SkCodec 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
2016-10-24 16:03:26 +00:00
static constexpr int kRepetitionCountInfinite = -1;
/**
* Return the number of times to repeat, if this image is animated. This number does not
* include the first play through of each frame. For example, a repetition count of 4 means
* that each frame is played 5 times and then the animation stops.
*
* It can return kRepetitionCountInfinite, a negative number, meaning that the animation
* should loop forever.
*
* May require reading the stream to find the repetition count.
*
* As such, future decoding calls may require a rewind.
*
* For still (non-animated) image codecs, this will return 0.
*/
int getRepetitionCount() {
return this->onGetRepetitionCount();
}
protected:
const SkEncodedInfo& getEncodedInfo() const { return fEncodedInfo; }
using XformFormat = skcms_PixelFormat;
SkCodec(SkEncodedInfo&&,
XformFormat srcFormat,
std::unique_ptr<SkStream>,
SkEncodedOrigin = kTopLeft_SkEncodedOrigin);
virtual SkISize onGetScaledDimensions(float /*desiredScale*/) const {
// By default, scaling is not supported.
return this->dimensions();
}
// FIXME: What to do about subsets??
/**
* Subclasses should override if they support dimensions other than the
* srcInfo's.
*/
virtual bool onDimensionsSupported(const SkISize&) {
return false;
}
virtual SkEncodedImageFormat onGetEncodedFormat() const = 0;
/**
* @param rowsDecoded When the encoded image stream is incomplete, this function
* will return kIncompleteInput and rowsDecoded will be set to
* the number of scanlines that were successfully decoded.
* This will allow getPixels() to fill the uninitialized memory.
*/
virtual Result onGetPixels(const SkImageInfo& info,
void* pixels, size_t rowBytes, const Options&,
int* rowsDecoded) = 0;
virtual bool onQueryYUV8(SkYUVASizeInfo*, SkYUVColorSpace*) const {
return false;
}
virtual Result onGetYUV8Planes(const SkYUVASizeInfo&,
void*[SkYUVASizeInfo::kMaxCount] /*planes*/) {
return kUnimplemented;
}
virtual bool onGetValidSubset(SkIRect* /*desiredSubset*/) const {
// By default, subsets are not supported.
return false;
}
/**
* If the stream was previously read, attempt to rewind.
*
* If the stream needed to be rewound, call onRewind.
* @returns true if the codec is at the right position and can be used.
* false if there was a failure to rewind.
*
* This is called by getPixels(), getYUV8Planes(), startIncrementalDecode() and
* startScanlineDecode(). Subclasses may call if they need to rewind at another time.
*/
bool SK_WARN_UNUSED_RESULT rewindIfNeeded();
/**
* Called by rewindIfNeeded, if the stream needed to be rewound.
*
* Subclasses should do any set up needed after a rewind.
*/
virtual bool onRewind() {
return true;
}
/**
* Get method for the input stream
*/
SkStream* stream() {
return fStream.get();
}
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
/**
* The remaining functions revolve around decoding scanlines.
*/
/**
* Most images types will be kTopDown and will not need to override this function.
*/
virtual SkScanlineOrder onGetScanlineOrder() const { return kTopDown_SkScanlineOrder; }
const SkImageInfo& dstInfo() const { return fDstInfo; }
const Options& options() const { return fOptions; }
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
/**
* Returns the number of scanlines that have been decoded so far.
* This is unaffected by the SkScanlineOrder.
*
* Returns -1 if we have not started a scanline decode.
*/
int currScanline() const { return fCurrScanline; }
virtual int onOutputScanline(int inputScanline) const;
/**
* Return whether we can convert to dst.
*
* Will be called for the appropriate frame, prior to initializing the colorXform.
*/
virtual bool conversionSupported(const SkImageInfo& dst, bool srcIsOpaque,
bool needsColorXform);
// Some classes never need a colorXform e.g.
// - ICO uses its embedded codec's colorXform
// - WBMP is just Black/White
virtual bool usesColorXform() const { return true; }
void applyColorXform(void* dst, const void* src, int count) const;
bool colorXform() const { return fXformTime != kNo_XformTime; }
bool xformOnDecode() const { return fXformTime == kDecodeRow_XformTime; }
virtual int onGetFrameCount() {
return 1;
}
virtual bool onGetFrameInfo(int, FrameInfo*) const {
return false;
Add support for multiple frames in SkCodec 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
2016-10-24 16:03:26 +00:00
}
virtual int onGetRepetitionCount() {
return 0;
}
private:
const SkEncodedInfo fEncodedInfo;
const XformFormat fSrcXformFormat;
std::unique_ptr<SkStream> fStream;
bool fNeedsRewind;
const SkEncodedOrigin fOrigin;
SkImageInfo fDstInfo;
Options fOptions;
enum XformTime {
kNo_XformTime,
kPalette_XformTime,
kDecodeRow_XformTime,
};
XformTime fXformTime;
XformFormat fDstXformFormat; // Based on fDstInfo.
skcms_ICCProfile fDstProfile;
skcms_AlphaFormat fDstXformAlphaFormat;
Make SkPngCodec decode progressively. This is a step towards using SkCodec in Chromium, where progressive decoding is necessary. Switch from using png_read_row (which expects all the data to be available) to png_process_data, which uses callbacks when rows are available. Create a new API for SkCodec, which supports progressive decoding and scanline decoding. Future changes will switch the other clients off of startScanlineDecode and get/skip-Scanlines to the new API. Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced PNG images. In the new API, interlaced PNG fits kTopDown. Also remove updateCurrScanline(), which was only used by the old implementation for interlaced PNG. DMSrcSink: - In CodecSrc::kScanline_Mode, use the new method for scanline decoding for the supported formats (just PNG and PNG-in-ICO for now). fuzz.cpp: - Remove reference to kNone_ScanlineOrder SkCodec: - Add new APIs: - startIncrementalDecode - incrementalDecode - Remove kNone_SkScanlineOrder and updateCurrScanline() - Set fDstInfo and fOptions in getPixels(). This may not be necessary for all implementations, but it simplifies things for SkPngCodec. SkPngCodec: - Implement new APIs - Switch from sk_read_fn/png_read_row etc to png_process_data - Expand AutoCleanPng's role to decode the header and create the SkPngCodec - Make the interlaced PNG decoder report how many lines were initialized during an incomplete decode SkIcoCodec: - Implement the new APIs; supported for PNG in ICO SkSampledCodec: - Call the new method for decoding scanlines, and fall back to the old method if the new version is unimplemented - Remove references to kNone_SkScanlineOrder tests/CodecPartial: - Add a test which decodes part of an image, then finishes the decode, and compares it to the straightforward method tests/CodecTest: - Add a test which decodes all scanlines using the new method - Repurpose the Codec_stripes test to decode using the new method in sections rather than all at once - In the method check(), add a parameter for whether the image supports the new method of scanline decoding, and be explicit about whether an image supports incomplete - Test incomplete PNG decodes. We should have been doing it anyway for non-interlaced (except for an image that is too small - one row), but the new method supports interlaced incomplete as well - Make test_invalid_parameters test the new method - Add a test to ensure that it's safe to fall back to scanline decoding without rewinding BUG=skia:4211 The new version was generally faster than the old version (but not significantly so). Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/ Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/ GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003 Review-Url: https://codereview.chromium.org/1997703003
2016-09-16 15:20:38 +00:00
// Only meaningful during scanline decodes.
int fCurrScanline;
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
bool fStartedIncrementalDecode;
Make SkPngCodec decode progressively. This is a step towards using SkCodec in Chromium, where progressive decoding is necessary. Switch from using png_read_row (which expects all the data to be available) to png_process_data, which uses callbacks when rows are available. Create a new API for SkCodec, which supports progressive decoding and scanline decoding. Future changes will switch the other clients off of startScanlineDecode and get/skip-Scanlines to the new API. Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced PNG images. In the new API, interlaced PNG fits kTopDown. Also remove updateCurrScanline(), which was only used by the old implementation for interlaced PNG. DMSrcSink: - In CodecSrc::kScanline_Mode, use the new method for scanline decoding for the supported formats (just PNG and PNG-in-ICO for now). fuzz.cpp: - Remove reference to kNone_ScanlineOrder SkCodec: - Add new APIs: - startIncrementalDecode - incrementalDecode - Remove kNone_SkScanlineOrder and updateCurrScanline() - Set fDstInfo and fOptions in getPixels(). This may not be necessary for all implementations, but it simplifies things for SkPngCodec. SkPngCodec: - Implement new APIs - Switch from sk_read_fn/png_read_row etc to png_process_data - Expand AutoCleanPng's role to decode the header and create the SkPngCodec - Make the interlaced PNG decoder report how many lines were initialized during an incomplete decode SkIcoCodec: - Implement the new APIs; supported for PNG in ICO SkSampledCodec: - Call the new method for decoding scanlines, and fall back to the old method if the new version is unimplemented - Remove references to kNone_SkScanlineOrder tests/CodecPartial: - Add a test which decodes part of an image, then finishes the decode, and compares it to the straightforward method tests/CodecTest: - Add a test which decodes all scanlines using the new method - Repurpose the Codec_stripes test to decode using the new method in sections rather than all at once - In the method check(), add a parameter for whether the image supports the new method of scanline decoding, and be explicit about whether an image supports incomplete - Test incomplete PNG decodes. We should have been doing it anyway for non-interlaced (except for an image that is too small - one row), but the new method supports interlaced incomplete as well - Make test_invalid_parameters test the new method - Add a test to ensure that it's safe to fall back to scanline decoding without rewinding BUG=skia:4211 The new version was generally faster than the old version (but not significantly so). Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/ Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/ GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003 Review-Url: https://codereview.chromium.org/1997703003
2016-09-16 15:20:38 +00:00
bool initializeColorXform(const SkImageInfo& dstInfo, SkEncodedInfo::Alpha, bool srcIsOpaque);
/**
* Return whether these dimensions are supported as a scale.
*
* The codec may choose to cache the information about scale and subset.
* Either way, the same information will be passed to onGetPixels/onStart
* on success.
*
* This must return true for a size returned from getScaledDimensions.
*/
bool dimensionsSupported(const SkISize& dim) {
return dim == this->dimensions() || this->onDimensionsSupported(dim);
}
Consolidate decoding frames into SkCodec Add a new private method to SkCodec that handles Options.fFrameIndex: - Check to ensure the index is valid - Call onGetFrameCount to force parsing the stream - Recursively call getPixels (it should be complete, so no need for incremental decoding) to decode the prior frame if necessary - Zero fill a RestoreBGColor frame Call the method in getPixels and startIncrementalDecode, and remove duplicate code from GIF and WEBP. Remove support for scaling frames beyond the first, which is currently unused. Preserve the feature of SkGifCodec that it will only parse to the end of the first frame if the first frame is asked for. (Also note that when we continue a partial frame, we won't force parsing the full stream.) If the client only wants the first frame, parsing the rest would be unnecessary. But if the client wants the second, we assume they will want any remaining frames, so we parse the remainder of the stream. This simplifies the code (so SkCodec does not have to ask its subclass to parse up to a particular frame). Update tests that relied on the old behavior: - Codec_partialAnim now hardcodes the bytes needed. Previously it relied on the old behavior that GIF only parsed up to the frame being decoded. - Codec_skipFullParse now only tests the first frame, since that is the case where it is important to skip a full parse. TBR=reed@google.com No changes to the public API. Change-Id: Ic2f075452dfeedb4e3e60e6cf4df33ee7bd38495 Reviewed-on: https://skia-review.googlesource.com/19276 Reviewed-by: Leon Scroggins <scroggo@google.com> Reviewed-by: Matt Sarett <msarett@google.com> Commit-Queue: Leon Scroggins <scroggo@google.com>
2017-06-12 20:41:09 +00:00
/**
* For multi-framed images, return the object with information about the frames.
*/
virtual const SkFrameHolder* getFrameHolder() const {
return nullptr;
}
/**
* Check for a valid Options.fFrameIndex, and decode prior frames if necessary.
*/
Result handleFrameIndex(const SkImageInfo&, void* pixels, size_t rowBytes, const Options&);
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
// Methods for scanline decoding.
virtual Result onStartScanlineDecode(const SkImageInfo& /*dstInfo*/,
const Options& /*options*/) {
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
return kUnimplemented;
}
Make SkPngCodec decode progressively. This is a step towards using SkCodec in Chromium, where progressive decoding is necessary. Switch from using png_read_row (which expects all the data to be available) to png_process_data, which uses callbacks when rows are available. Create a new API for SkCodec, which supports progressive decoding and scanline decoding. Future changes will switch the other clients off of startScanlineDecode and get/skip-Scanlines to the new API. Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced PNG images. In the new API, interlaced PNG fits kTopDown. Also remove updateCurrScanline(), which was only used by the old implementation for interlaced PNG. DMSrcSink: - In CodecSrc::kScanline_Mode, use the new method for scanline decoding for the supported formats (just PNG and PNG-in-ICO for now). fuzz.cpp: - Remove reference to kNone_ScanlineOrder SkCodec: - Add new APIs: - startIncrementalDecode - incrementalDecode - Remove kNone_SkScanlineOrder and updateCurrScanline() - Set fDstInfo and fOptions in getPixels(). This may not be necessary for all implementations, but it simplifies things for SkPngCodec. SkPngCodec: - Implement new APIs - Switch from sk_read_fn/png_read_row etc to png_process_data - Expand AutoCleanPng's role to decode the header and create the SkPngCodec - Make the interlaced PNG decoder report how many lines were initialized during an incomplete decode SkIcoCodec: - Implement the new APIs; supported for PNG in ICO SkSampledCodec: - Call the new method for decoding scanlines, and fall back to the old method if the new version is unimplemented - Remove references to kNone_SkScanlineOrder tests/CodecPartial: - Add a test which decodes part of an image, then finishes the decode, and compares it to the straightforward method tests/CodecTest: - Add a test which decodes all scanlines using the new method - Repurpose the Codec_stripes test to decode using the new method in sections rather than all at once - In the method check(), add a parameter for whether the image supports the new method of scanline decoding, and be explicit about whether an image supports incomplete - Test incomplete PNG decodes. We should have been doing it anyway for non-interlaced (except for an image that is too small - one row), but the new method supports interlaced incomplete as well - Make test_invalid_parameters test the new method - Add a test to ensure that it's safe to fall back to scanline decoding without rewinding BUG=skia:4211 The new version was generally faster than the old version (but not significantly so). Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/ Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/ GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003 Review-Url: https://codereview.chromium.org/1997703003
2016-09-16 15:20:38 +00:00
virtual Result onStartIncrementalDecode(const SkImageInfo& /*dstInfo*/, void*, size_t,
const Options&) {
Make SkPngCodec decode progressively. This is a step towards using SkCodec in Chromium, where progressive decoding is necessary. Switch from using png_read_row (which expects all the data to be available) to png_process_data, which uses callbacks when rows are available. Create a new API for SkCodec, which supports progressive decoding and scanline decoding. Future changes will switch the other clients off of startScanlineDecode and get/skip-Scanlines to the new API. Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced PNG images. In the new API, interlaced PNG fits kTopDown. Also remove updateCurrScanline(), which was only used by the old implementation for interlaced PNG. DMSrcSink: - In CodecSrc::kScanline_Mode, use the new method for scanline decoding for the supported formats (just PNG and PNG-in-ICO for now). fuzz.cpp: - Remove reference to kNone_ScanlineOrder SkCodec: - Add new APIs: - startIncrementalDecode - incrementalDecode - Remove kNone_SkScanlineOrder and updateCurrScanline() - Set fDstInfo and fOptions in getPixels(). This may not be necessary for all implementations, but it simplifies things for SkPngCodec. SkPngCodec: - Implement new APIs - Switch from sk_read_fn/png_read_row etc to png_process_data - Expand AutoCleanPng's role to decode the header and create the SkPngCodec - Make the interlaced PNG decoder report how many lines were initialized during an incomplete decode SkIcoCodec: - Implement the new APIs; supported for PNG in ICO SkSampledCodec: - Call the new method for decoding scanlines, and fall back to the old method if the new version is unimplemented - Remove references to kNone_SkScanlineOrder tests/CodecPartial: - Add a test which decodes part of an image, then finishes the decode, and compares it to the straightforward method tests/CodecTest: - Add a test which decodes all scanlines using the new method - Repurpose the Codec_stripes test to decode using the new method in sections rather than all at once - In the method check(), add a parameter for whether the image supports the new method of scanline decoding, and be explicit about whether an image supports incomplete - Test incomplete PNG decodes. We should have been doing it anyway for non-interlaced (except for an image that is too small - one row), but the new method supports interlaced incomplete as well - Make test_invalid_parameters test the new method - Add a test to ensure that it's safe to fall back to scanline decoding without rewinding BUG=skia:4211 The new version was generally faster than the old version (but not significantly so). Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/ Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/ GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003 Review-Url: https://codereview.chromium.org/1997703003
2016-09-16 15:20:38 +00:00
return kUnimplemented;
}
virtual Result onIncrementalDecode(int*) {
return kUnimplemented;
}
virtual bool onSkipScanlines(int /*countLines*/) { return false; }
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
virtual int onGetScanlines(void* /*dst*/, int /*countLines*/, size_t /*rowBytes*/) { return 0; }
/**
* On an incomplete decode, getPixels() and getScanlines() will call this function
* to fill any uinitialized memory.
*
* @param dstInfo Contains the destination color type
* Contains the destination alpha type
* Contains the destination width
* The height stored in this info is unused
* @param dst Pointer to the start of destination pixel memory
* @param rowBytes Stride length in destination pixel memory
* @param zeroInit Indicates if memory is zero initialized
* @param linesRequested Number of lines that the client requested
* @param linesDecoded Number of lines that were successfully decoded
*/
void fillIncompleteImage(const SkImageInfo& dstInfo, void* dst, size_t rowBytes,
ZeroInitialized zeroInit, int linesRequested, int linesDecoded);
Merge SkCodec with SkScanlineDecoder 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
2015-09-30 15:57:13 +00:00
/**
* Return an object which will allow forcing scanline decodes to sample in X.
*
* May create a sampler, if one is not currently being used. Otherwise, does
* not affect ownership.
*
Add support for multiple frames in SkCodec 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
2016-10-24 16:03:26 +00:00
* Only valid during scanline decoding or incremental decoding.
*/
virtual SkSampler* getSampler(bool /*createIfNecessary*/) { return nullptr; }
Make SkPngCodec decode progressively. This is a step towards using SkCodec in Chromium, where progressive decoding is necessary. Switch from using png_read_row (which expects all the data to be available) to png_process_data, which uses callbacks when rows are available. Create a new API for SkCodec, which supports progressive decoding and scanline decoding. Future changes will switch the other clients off of startScanlineDecode and get/skip-Scanlines to the new API. Remove SkCodec::kNone_ScanlineOrder, which was only used for interlaced PNG images. In the new API, interlaced PNG fits kTopDown. Also remove updateCurrScanline(), which was only used by the old implementation for interlaced PNG. DMSrcSink: - In CodecSrc::kScanline_Mode, use the new method for scanline decoding for the supported formats (just PNG and PNG-in-ICO for now). fuzz.cpp: - Remove reference to kNone_ScanlineOrder SkCodec: - Add new APIs: - startIncrementalDecode - incrementalDecode - Remove kNone_SkScanlineOrder and updateCurrScanline() - Set fDstInfo and fOptions in getPixels(). This may not be necessary for all implementations, but it simplifies things for SkPngCodec. SkPngCodec: - Implement new APIs - Switch from sk_read_fn/png_read_row etc to png_process_data - Expand AutoCleanPng's role to decode the header and create the SkPngCodec - Make the interlaced PNG decoder report how many lines were initialized during an incomplete decode SkIcoCodec: - Implement the new APIs; supported for PNG in ICO SkSampledCodec: - Call the new method for decoding scanlines, and fall back to the old method if the new version is unimplemented - Remove references to kNone_SkScanlineOrder tests/CodecPartial: - Add a test which decodes part of an image, then finishes the decode, and compares it to the straightforward method tests/CodecTest: - Add a test which decodes all scanlines using the new method - Repurpose the Codec_stripes test to decode using the new method in sections rather than all at once - In the method check(), add a parameter for whether the image supports the new method of scanline decoding, and be explicit about whether an image supports incomplete - Test incomplete PNG decodes. We should have been doing it anyway for non-interlaced (except for an image that is too small - one row), but the new method supports interlaced incomplete as well - Make test_invalid_parameters test the new method - Add a test to ensure that it's safe to fall back to scanline decoding without rewinding BUG=skia:4211 The new version was generally faster than the old version (but not significantly so). Some raw performance differences can be found at https://docs.google.com/a/google.com/spreadsheets/d/1Gis3aRCEa72qBNDRMgGDg3jD-pMgO-FXldlNF9ejo4o/ Design doc can be found at https://docs.google.com/a/google.com/document/d/11Mn8-ePDKwVEMCjs3nWwSjxcSpJ_Cu8DF57KNtUmgLM/ GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1997703003 Review-Url: https://codereview.chromium.org/1997703003
2016-09-16 15:20:38 +00:00
friend class DM::CodecSrc; // for fillIncompleteImage
friend class SkSampledCodec;
friend class SkIcoCodec;
friend class SkAndroidCodec; // for fEncodedInfo
};
#endif // SkCodec_DEFINED