aboutsummaryrefslogtreecommitdiffhomepage
path: root/tests/CodexTest.cpp
Commit message (Collapse)AuthorAge
...
* Scanline decoding for wbmpGravatar msarett2015-08-05
| | | | | | | | | | | | | | | We are also changing the wbmp to use SkSwizzler. This will allow us to take advantage of the sampling routines that are being implemented in SkSwizzler. The image in this upload came from: https://commons.wikimedia.org/wiki/File:Android_robot.png It is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license. BUG=skia: Review URL: https://codereview.chromium.org/1254483004
* Create a scanline decoder without creating a codecGravatar scroggo2015-08-04
| | | | | | | | | | | | | | Prior to this CL, if a client wanted to decode scanlines, they had to create an SkCodec in order to get an SkScanlineDecoder. This introduces complications if input data is not easily shared between the two objects. Instead, add methods to SkScanlineDecoder for creating a new one from input data, and remove the creation functions from SkCodec. Update DM and tests. Review URL: https://codereview.chromium.org/1267583002
* 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
* Allow creating multiple scanline decoders.Gravatar scroggo2015-07-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make getScanlineDecoder return a new object each time, which is owned by the caller, and independent from any existing scanline decoders and the SkCodec itself. Since the SkCodec already contains the entire state machine, and it is used by the scanline decoders, simply create a new SkCodec which is now owned by the scanline decoder. Move code that cleans up after using a scanline decoder into its destructor One side effect is that creating the first scanline decoder requires a duplication of the stream and re-reading the header. (With some more complexity/changes, we could pass the state machine to the scanline decoder and make the SkCodec recreate its own state machine instead.) The typical client of the scanline decoder (region decoder) uses an SkMemoryStream, so the duplication is cheap, although we should consider the extra time to reread the header/recreate the state machine. (If/when we use the scanline decoder for other purposes, where the stream may not be cheaply duplicated, we should consider passing the state machine.) One (intended) result of this change is that a client can create a new scanline decoder in a new thread, and decode different pieces of the image simultaneously. In SkPngCodec::decodePalette, use fBitDepth rather than a parameter. Review URL: https://codereview.chromium.org/1230033004
* 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
* In the case of subset decodes, we will often not decode toGravatar msarett2015-07-01
| | | | | | | | | | | | | | the bottom of the image. In our code before this patch, this would result in cleanup code in onFinish() never being called. We can allow subclasses to take ownership of the SkScanlineDecoder in order to make sure that it is finished/deleted before deleting the decode manager. BUG=skia: Review URL: https://codereview.chromium.org/1212593003
* 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
* Implementing a scanline decoder for jpegGravatar msarett2015-04-29
| | | | | | BUG=skia:3257 Review URL: https://codereview.chromium.org/1092303003
* Ensure that we create a NULL codec for images with zero dimensionsGravatar msarett2015-04-23
| | | | | | | BUG=skia:3534 BUG=skia:3257 Review URL: https://codereview.chromium.org/1091043003
* SkJpegCodecGravatar msarett2015-04-15
| | | | | | | | | | | | Enables basic decoding for jpegs Includes rewinding 565, YUV, and Jpeg encoding are not yet implemented BUG=skia:3257 Review URL: https://codereview.chromium.org/1076923002
* ***Disables swizzles to 565.Gravatar msarett2015-04-09
| | | | | | | | | | | | | | | | | | | | | | | We may want to enable swizzles to 565 for images that are encoded in a format similar to 565, however, we do not want to take images that decode naturally to kN32 and then convert them to 565. ***Enable swizzles to kIndex_8. For images encoded in a color table format, we suggest that they be decoded to kIndex_8. When we decode, we only allow conversion to kIndex_8 if it matches the suggested color type (except wbmp which seems good as is). ***Modify dm to test images that decode to kIndex_8. BUG=skia:3257 BUG=skia:3440 Review URL: https://codereview.chromium.org/1055743003
* Get rid of leaks in SkCodec::NewFromStream.Gravatar scroggo2015-04-03
| | | | | | | | | | | | | | | | | | | | SkCodec::NewFromStream claims to delete the passed in SkStream on failure. This allows the caller to pass an SkStream to the function and not worry about deleting it depending on the return value. Most of our SkCodecs did not honor this contract though. Update them to delete the stream on failure. Further, update SkCodec::NewFromStream to delete the stream if it did not match any subclass, and delete the SkCodec if we decided to return NULL because it was too big. Add a test which tests streams which represent the beginnings of supported format types but do not contain enough data to create an SkCodec. The interesting part of the test is when we run it on ASAN, which will report that we leaked something without the other changes. BUG=skia:3257 Review URL: https://codereview.chromium.org/1058873006
* Ico test with embedded pngGravatar msarett2015-04-01
| | | | | | BUG=skia:3257 Review URL: https://codereview.chromium.org/1054673002
* SkCodec::onGetScanlineDecoder must call rewind.Gravatar scroggo2015-04-01
| | | | | | | | | | | | | | | | | | | | This mirrors the behavior in onGetPixels, and allows the implementation to share code for handling calls to rewindIfNeeded. This also fixes a bug where getScanlineDecoder was calling rewindIfNeeded and treating the result as a bool. In SkPngCodec, factor out the code to call rewindIfNeeded, and call it in both onGetPixels and onGetScanlineDecoder. Update the test to include testing the scanline decoder. Rename "gen" to "codec" now that it must be an SkCodec. BUG=skia:3257 Depends on https://codereview.chromium.org/1048423003/ (DIFFERENT ISSUE). Review URL: https://codereview.chromium.org/1050893002
* Acknowledge that SkIcoCodec can rewind and test it.Gravatar scroggo2015-04-01
| | | | | | | | | | | | | | Since SkIcoCodec has an SkCodec for its encoded images, backed by SkMemoryStreams, the SkMemoryStream can always rewind, and will be rewound by the sub-codec if necessary (now that SkBmpCodec and SkPngCodec support rewinding). Depends on https://codereview.chromium.org/1057483003/ and https://codereview.chromium.org/1048423003/ (DIFFERENT ISSUES). BUG=skia:3257 Review URL: https://codereview.chromium.org/1054603002
* Make SkPngCodec support rewinding properly.Gravatar scroggo2015-04-01
| | | | | | | | | | | | | | Separate out the code for reading the header, and use it to reinitialize fPng_ptr and fInfo_ptr after a rewind. Use common code to clean up fPng_ptr and fInfo_ptr, and set them to NULL and treat them as NULL as appropriate. Update the test to expect SkPngCodec to succeed. BUG=skia:3257 Review URL: https://codereview.chromium.org/1048423003
* Handle rewinds in SkBmpCodec.Gravatar scroggo2015-04-01
| | | | | | | | Factor our BMP code for reading the header, and call it after a rewind. BUG=skia:3257 Review URL: https://codereview.chromium.org/1057483003
* SkCodec: add wbmp classGravatar halcanary2015-03-27
Review URL: https://codereview.chromium.org/1006583005
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-15 22:15:03 +0000