aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/codec/SkWebpCodec.cpp
Commit message (Collapse)AuthorAge
* Switch SkAutoMalloc to SkAutoTMalloc to avoid castGravatar scroggo2015-12-10
| | | | | | | | | | | | Make SkAutoTMalloc's interface look more like SkAutoMalloc: - add free(), which does what you expect - make reset() return a pointer fPtr No public API changes (SkAutoTMalloc is in include/private) BUG=skia:2148 Review URL: https://codereview.chromium.org/1516833003
* Make SkCodec support peek() and read()Gravatar scroggo2015-12-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Update SkCodec's dox to point out that some of the data must be read twice in order to decode - Add an accessor that reports how much is needed for reading twice - Make SkCodec default to use peek() If an input stream supports peek()ing, peek() instead of reading. This way the stream need not implement rewind() - Make SkCodec use read() + rewind() as a backup So that streams without peek() implemented can still function properly (assuming they can rewind). - read everything we may need to determine the format once In SkCodec::NewFromStream, peek()/read() 14 bytes, which is enough to read all of the types we support. Pass the buffer to each subtype, which will have enough info to determine whether it is the right type. This simplifies the code and results in less reading and rewinding. - NOTE: SkWbmpCodec needs the following number of bytes for the header + 1 (type) + 1 (reserved) + 3 (width - bytes needed to support up to 0xFFFF) + 3 (height - bytes needed to support up to 0xFFFF) = 8 - in SkWebpCodec, support using read + rewind as a backup if peek does not work. A change in Android will add peek() to JavaInputStreamAdapter. BUG=skia:3257 Review URL: https://codereview.chromium.org/1472123002
* Add subsetting to SkScanlineDecoderGravatar msarett2015-10-13
| | | | | | | | | | | | This CL allows the SkScanlineDecoder to decode partial scanlines. This is a first step in efficiently implementing subsetting in SkScaledCodec. BUG=skia:4209 Review URL: https://codereview.chromium.org/1390213002
* Fill incomplete images in SkCodec parent classGravatar msarett2015-10-09
| | | | | | | | | | | | | | | | | | | | | | | | | Rather than implementing some sort of "fill" in every SkCodec subclass for incomplete images, let's make the parent class handle this situation. This includes an API change to SkCodec.h SkCodec::getScanlines() now returns the number of lines it read successfully, rather than an SkCodec::Result enum. getScanlines() most often fails on an incomplete input, in which case it is useful to know how many lines were successfully decoded - this provides more information than kIncomplete vs kSuccess. We do lose information when the API is used improperly, as we are no longer able to return kInvalidParameter or kScanlineNotStarted. Known Issues: Does not work for incomplete fFrameIsSubset gifs. Does not work for incomplete icos. BUG=skia: Review URL: https://codereview.chromium.org/1332053002
* Move all knowledge of X sampling into SkScaledCodecGravatar scroggo2015-10-02
| | | | | | | | | | | | | | | | | | | | | | | Prior to this CL, each SkCodec subclass that allows sampling does an extra check in onStartScanlineDecode to determine whether the X dimension is supported for sampling. Remove this check, and provide a way for SkScaledCodec to directly access the SkSwizzler, and update it to do sampling. This way, the SkCodec knows nothing of sampling, but we can still save the extra step of sampling afterwards. FIXME: SkBmpRLECodec still calls SkScaledCodec::DimensionsSupported. It seems like it could directly support sampling, rather than dealing with SkScaledCodec (partially). Add a new base class for SkSwizzler. It allows updating the swizzler after it was created, which is done by SkScaledCodec. Modify SkSwizzler's constructor/factory function to stop taking any info about sampling, assume the sample size is one, and move modifying that into a virtual function overridden from the base class. BUG=skia:4284 Review URL: https://codereview.chromium.org/1372973002
* Call rewindIfNeeded in SkCodecGravatar scroggo2015-09-30
| | | | | | | | | | Rather than calling it in each subclass, call it once in the base class. Call it first, since other steps may modify internal structures which would be replaced by a call to onRewind. BUG=skia:4284 Review URL: https://codereview.chromium.org/1381483002
* Style Change: NULL->nullptrGravatar halcanary2015-08-27
| | | | | | DOCS_PREVIEW= https://skia.org/?cl=1316233002 Review URL: https://codereview.chromium.org/1316233002
* Style Change: SkNEW->new; SkDELETE->deleteGravatar halcanary2015-08-26
| | | | | | DOCS_PREVIEW= https://skia.org/?cl=1316123003 Review URL: https://codereview.chromium.org/1316123003
* Support more swizzles to 565 in SkCodecGravatar scroggo2015-08-14
| | | | | | | | | | | | | | | | | | | | | | | Add more swizzling functions for swizzling to 565. Much of this code was revived from crrev.com/1055743003 (for BMP). Also added swizzling functions for WBMP. Consolidate the static function conversion_possible. In SkCodec::getPixels, check that the alphatype corresponds to the colorType. This prevents requesting 565 + non-opaque. In SkIcoCodec, report that the image is unpremul (instead of whatever the largest embedded codec thinks), but modify the requested info to have the alpha type expected/required by the embedded codec. Add tests for decoding to 565. BUG=skia:3257 BUG=skia:3683 Review URL: https://codereview.chromium.org/1277213002
* Consolidate SkCodec functions for handling rewindGravatar scroggo2015-08-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, many of our codec implementations followed the same pattern (often in a function named handleRewind): switch (this->rewindIfNeeded()) { case CouldNotRewind: return CouldNotRewind; case NoRewindNecessary: // keep going break; case Rewound: <re-read header etc> break; } In this CL, remove the enum, and put the piece that happens in the Rewound case into a virtual function, onRewind. rewindIfNeeded now contains the common pieces from various functions named handleRewind. In SkBmpCodec, add a function that returns whether the BMP is in ICO, so it can have a common implementation for onRewind. BUG=skia:3257 Review URL: https://codereview.chromium.org/1288483002
* Let SkWebpCodec decode to 565Gravatar scroggo2015-08-06
| | | | | | BUG=skia:3257 Review URL: https://codereview.chromium.org/1277893002
* Add the ability to decode a subset to SkCodecGravatar scroggo2015-07-22
| | | | | | | | | | | | | | | | | | | | | | | | This allows codecs that support subsets natively (i.e. WEBP) to do so. Add a field on SkCodec::Options representing the subset. Add a method on SkCodec to find a valid subset which approximately matches a desired subset. Implement subset decodes in SkWebpCodec. Add a test in DM for decoding subsets. Notice that we only start on even boundaries. This is due to the way libwebp's API works. SkWEBPImageDecoder does not take this into account, which results in visual artifacts. FIXME: Subsets with scaling are not pixel identical, but close. (This may be fine, though - they are not perceptually different. We'll just need to mark another set of images in gold as valid, once https://skbug.com/4038 is fixed, so we can tests scaled webp without generating new images on each run.) Review URL: https://codereview.chromium.org/1240143002
* SkCodec no longer inherits from SkImageGenerator.Gravatar scroggo2015-07-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SkImageGenerator makes some assumptions that are not necessarily valid for SkCodec. For example, SkCodec does not assume that it can always be rewound. We also have an ongoing question of what an SkCodec should report as its default settings (i.e. the return from getInfo). It makes sense for an SkCodec to report that its pixels are unpremultiplied, if that is the case for the underlying data, but if a client of SkImageGenerator uses the default settings (as many do), they will receive unpremultiplied pixels which cannot (currently) be drawn with Skia. We may ultimately decide to revisit SkCodec reporting an SkImageInfo, but I have left it unchanged for now. Import features of SkImageGenerator used by SkCodec into SkCodec. I have left SkImageGenerator unchanged for now, but it no longer needs Result or Options. This will require changes to Chromium. Manually handle the lifetime of fScanlineDecoder, so SkScanlineDecoder.h can include SkCodec.h (where Result is), and SkCodec.h does not need to include it (to delete fScanlineDecoder). In many places, make the following simple changes: - Now include SkScanlineDecoder.h, which is no longer included by SkCodec.h - Use the enums in SkCodec, rather than SkImageGenerator - Stop including SkImageGenerator.h where no longer needed Review URL: https://codereview.chromium.org/1220733013
* Prevent webp from producing 0 dimensional imagesGravatar msarett2015-06-19
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1196643002
* Add SkWebpCodec, for decoding .webp images.Gravatar scroggo2015-06-18
Based on SkImageDecoder_libwebp. TODO: Support YUV? (Longer term - may influence our API for SkImageGenerator) BUG=skia:3257 Review URL: https://codereview.chromium.org/1044433002
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-06 14:10:11 +0000