aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/codec
Commit message (Collapse)AuthorAge
* Remove SkNEW and SkDELETE macrosGravatar mdempsky2015-09-22
| | | | | | | | | | | | | | | This CL removes the uses of SkNEW that have resprouted since commit 385fe4d, and removes the macros entirely now that Android and Chromium have been cleaned up to no longer depend on them. A bunch of files implicitly depend on #include <new> from SkPostConfig.h still though, so keep that for now. To be fixed in a followup CL. [mtklein mucking around] Only public API removed. TBR=reed@google.com Review URL: https://codereview.chromium.org/1360653004
* Disable dithering in libjpeg-turbo for 565 decodesGravatar msarett2015-09-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | libjpeg-turbo turns on dithering by default. When we decode to RGBA, it uses Floyd-Steinberg dithering - consistent with the libjpeg6b gold standard, When we decode to 565, it uses ordered dithering. Ordered dithering for 565 is not part of the 6b standard (libjpeg6b doesn't even support 565) and is causing us a number of issues: (1) Ordered dithering + nearest neighbor sampling is causing checkerboard visual artifacts in some outputs. (2) The ordered dither function in libjpeg-turbo actually behaves differently depending on the alignment of the memory that it decodes into. This means that two image decodes that should be identical may look different just because they decode into different memory blocks. This was causing some diffs on Gold with the scanline_subset test that were causing me some confusion. (3) Maybe not the best evidence, but visually I can't tell a difference with and without dithering (except when nearest neighbor scaling causes the checkerboard artifact). (4) Turning off dithering should be a more significant performance improvement than you might expect. libjpeg-turbo has SIMD color conversions to 565, but when dithering is on, it defaults to scalar code. This CL should make every jpeg decode to 565 on Gold look slightly different. Yay! BUG=skia: Review URL: https://codereview.chromium.org/1349563007
* Use rounding when converting desiredScale to a sampleSizeGravatar msarett2015-09-18
| | | | | | | | | | | | | | | | | | | | | Right now we have a bug in Gold where some images are labeled _0.167 and others are labeled _0.166. They are all 1/6 scales and should be labeled the same way and compared. The fix involves changing 0.166 to 0.167 in the list of scales that we test on, but SkScaledCodec does not scale to 0.167 as I expected. SkScaledCodec converts 0.167 to sampleSize = 5.999 and then casts to sampleSize = 5. I would argue that we should do a true round, so 0.167 represents a sampleSize of 6. In general, this CL change onGetScaledDimensions so that we now round desiredScale to the nearest sampleSize. BUG=skia: Review URL: https://codereview.chromium.org/1356923002
* Scanline decoding for gifsGravatar msarett2015-09-07
| | | | | | | | BUG=skia: Committed: https://skia.googlesource.com/skia/+/e9c10b9121887e8c300bd41357461418e061984d Review URL: https://codereview.chromium.org/1305123002
* Revert of Scanline decoding for gifs (patchset #15 id:380001 of ↵Gravatar jcgregorio2015-09-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1305123002/ ) Reason for revert: Breaks the build with SkScanlineDecoder.h not found: http://build.chromium.org/p/client.skia/builders/Linux%20Builder/builds/3722/steps/compile/logs/stdio ../../third_party/skia/src/utils/SkBitmapRegionCanvas.h:10:10: fatal error: 'SkScanlineDecoder.h' file not found #include "SkScanlineDecoder.h" Original issue's description: > Scanline decoding for gifs > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/e9c10b9121887e8c300bd41357461418e061984d TBR=scroggo@google.com,djsollen@google.com,msarett@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1320273004
* Scanline decoding for gifsGravatar msarett2015-09-04
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1305123002
* Ico bug fix for opaque embedded imagesGravatar msarett2015-09-04
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1327963004
* Fix bug in ico decodesGravatar msarett2015-09-02
| | | | | | | | | | | Some icos have been looking a bit strange in Gold. Looks like the cause was that we were decoding to kUnpremul accidentally. BUG=skia: Review URL: https://codereview.chromium.org/1321913003
* Fix bmp bug in ReadHeader()Gravatar msarett2015-09-01
| | | | | | | | | | | | | For BmpMaskCodecs, we need to skip any offset after the header to get to the start of pixel data. Before this fix, we only skipped this data when codecOut is non-NULL (instead of on every call to ReadHeader()). https://gold.skia.org/search?q=1&neg=true&unt=false&query=name%3Drgb16-565pal.bmp_0.200%26name%3Drgb16-565pal.bmp%26name%3Drgb16-565pal.bmp_0.250%26name%3Drgb16-565pal.bmp_0.333%26name%3Drgb16-565pal.bmp_0.375%26name%3Drgb16-565pal.bmp_0.400%26name%3Drgb16-565pal.bmp_0.500%26source_type%3Dimage BUG=skia: Review URL: https://codereview.chromium.org/1318393004
* Call standard libjpeg/libjpeg-turbo APIsGravatar msarett2015-09-01
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1322623004
* Scanline decoding for bmpGravatar msarett2015-08-31
| | | | | | | | | | | | | Redesigns SkScanlineDecoder.h to indicate the ordering in which the scanlines are provided Refactors SkSwizzler::Fill() to include the zeroInit check and to actually be correct. BUG=skia:3257 BUG=skia:4198 Review URL: https://codereview.chromium.org/1287423002
* Interlaced gifs without the iteratorGravatar msarett2015-08-28
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1315583003
* Some codec code formatting cleanup.Gravatar bungeman2015-08-27
| | | | | | | | | While looking at users of SkTAddOffset, some unwanted casts were found. These casts are removed and the lines reformatted. However, the formatting of the rest of the file was unhappy, so this is really just a formatting clean-up. Review URL: https://codereview.chromium.org/1301393010
* 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
* Update giflib to 5.1.1 (AOSP hash)Gravatar msarett2015-08-24
| | | | | | | | | | This also disables warnings in giflib and fixes compile warnings in icu, in order to fix a skia bug. BUG=skia:4220 Review URL: https://codereview.chromium.org/1314633002
* Clean up ifdefs in SkGifCodecGravatar msarett2015-08-21
| | | | | | | | | Since codec uses the same version of giflib everywhere, I believe these are unnecessary. BUG=skia: Review URL: https://codereview.chromium.org/1309763002
* Move SkTemplates.h to private.Gravatar bungeman2015-08-19
| | | | | | | | SkTemplates.h contains a number of Skia specific utilities which are not designed for external use. In addition to reducing the external support burden, this will allow Skia to freely refactor this file. Review URL: https://codereview.chromium.org/1272293004
* Prefer native scaling to samplingGravatar msarett2015-08-18
| | | | | | | | | | | | | | | | | | | | | In the cases we have come across so far, native scaling has better performance and correctness than sampling. If native scaling is supported we want to use it. Jpegs native scale rounds up. Ex: An 11x11 image with sampleSize=8 scales to 2x2. SkScaledCodec rounds down. Ex: An 11x11 image with sampleSize=8 scales to 1x1. Before the CL, we would choose to use SkScaledCodec because it scales closer to the "ideal" scale. I think we want to go with the native option as long as its within 1 of the ideal value. BUG=skia: Review URL: https://codereview.chromium.org/1284243004
* 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
* SkScaledCodec classGravatar emmaleer2015-08-14
| | | | | | | | | | | | | | | | | | | | | | | | This class does scaling by using a scanlineDecoder. getScanlines and skipScanlines are used for y sampling, the swizzler is used for x sampling this class is currently only working for png and jpeg images I will update other Codec types to work soon For SkJpegCodec to implement width wise swizzling it now uses a swizzler. I ran performance tests on this change. Here are the performance test results: https://docs.google.com/a/google.com/spreadsheets/d/1D7-Q_GXD_dI68LZO005NNvb8Wq2Ee0wEBEPG72671yw/edit?usp=sharing BUG=skia: Committed: https://skia.googlesource.com/skia/+/0944100ac89f797714eeae0cf2875e2335ff52ee Committed: https://skia.googlesource.com/skia/+/d518ea7927f9f4e0ed5b4134d1b4f48243855a47 Committed: https://skia.googlesource.com/skia/+/b157917507d4f7d2651f0aeb566d31603cc02240 Review URL: https://codereview.chromium.org/1260673002
* Revert of SkScaledCodec class (patchset #35 id:680001 of ↵Gravatar egdaniel2015-08-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1260673002/ ) Reason for revert: breaking ubuntu bots Original issue's description: > SkScaledCodec class > > This class does scaling by using a scanlineDecoder. > getScanlines and skipScanlines are used for y sampling, > the swizzler is used for x sampling > > this class is currently only working for png and jpeg images > I will update other Codec types to work soon > > For SkJpegCodec to implement width wise swizzling it now > uses a swizzler. I ran performance tests on this change. > Here are the performance test results: > https://docs.google.com/a/google.com/spreadsheets/d/1D7-Q_GXD_dI68LZO005NNvb8Wq2Ee0wEBEPG72671yw/edit?usp=sharing > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/0944100ac89f797714eeae0cf2875e2335ff52ee > > Committed: https://skia.googlesource.com/skia/+/d518ea7927f9f4e0ed5b4134d1b4f48243855a47 > > Committed: https://skia.googlesource.com/skia/+/b157917507d4f7d2651f0aeb566d31603cc02240 TBR=scroggo@google.com,msarett@google.com,djsollen@google.com,mtklein@google.com,emmaleer@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1285173003
* SkScaledCodec classGravatar emmaleer2015-08-14
| | | | | | | | | | | | | | | | | | | | | | This class does scaling by using a scanlineDecoder. getScanlines and skipScanlines are used for y sampling, the swizzler is used for x sampling this class is currently only working for png and jpeg images I will update other Codec types to work soon For SkJpegCodec to implement width wise swizzling it now uses a swizzler. I ran performance tests on this change. Here are the performance test results: https://docs.google.com/a/google.com/spreadsheets/d/1D7-Q_GXD_dI68LZO005NNvb8Wq2Ee0wEBEPG72671yw/edit?usp=sharing BUG=skia: Committed: https://skia.googlesource.com/skia/+/0944100ac89f797714eeae0cf2875e2335ff52ee Committed: https://skia.googlesource.com/skia/+/d518ea7927f9f4e0ed5b4134d1b4f48243855a47 Review URL: https://codereview.chromium.org/1260673002
* Revert of SkScaledCodec class (patchset #34 id:660001 of ↵Gravatar emmaleer2015-08-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1260673002/ ) Reason for revert: Seg-faulting: http://build.chromium.org/p/client.skia/builders/Test-Ubuntu-GCC-GCE-CPU-AVX2-x86-Release/builds/1608/steps/dm/logs/stdio Original issue's description: > SkScaledCodec class > > This class does scaling by using a scanlineDecoder. > getScanlines and skipScanlines are used for y sampling, > the swizzler is used for x sampling > > this class is currently only working for png and jpeg images > I will update other Codec types to work soon > > For SkJpegCodec to implement width wise swizzling it now > uses a swizzler. I ran performance tests on this change. > Here are the performance test results: > https://docs.google.com/a/google.com/spreadsheets/d/1D7-Q_GXD_dI68LZO005NNvb8Wq2Ee0wEBEPG72671yw/edit?usp=sharing > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/0944100ac89f797714eeae0cf2875e2335ff52ee > > Committed: https://skia.googlesource.com/skia/+/d518ea7927f9f4e0ed5b4134d1b4f48243855a47 TBR=scroggo@google.com,msarett@google.com,djsollen@google.com,mtklein@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1294613002
* SkScaledCodec classGravatar emmaleer2015-08-13
| | | | | | | | | | | | | | | | | | | | This class does scaling by using a scanlineDecoder. getScanlines and skipScanlines are used for y sampling, the swizzler is used for x sampling this class is currently only working for png and jpeg images I will update other Codec types to work soon For SkJpegCodec to implement width wise swizzling it now uses a swizzler. I ran performance tests on this change. Here are the performance test results: https://docs.google.com/a/google.com/spreadsheets/d/1D7-Q_GXD_dI68LZO005NNvb8Wq2Ee0wEBEPG72671yw/edit?usp=sharing BUG=skia: Committed: https://skia.googlesource.com/skia/+/0944100ac89f797714eeae0cf2875e2335ff52ee Review URL: https://codereview.chromium.org/1260673002
* Revert of SkScaledCodec class (patchset #32 id:620001 of ↵Gravatar emmaleer2015-08-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1260673002/ ) Reason for revert: Segfaulting: http://build.chromium.org/p/client.skia/builders/Test-Ubuntu-GCC-GCE-CPU-AVX2-x86-Release/builds/1605/steps/dm/logs/stdio Original issue's description: > SkScaledCodec class > > This class does scaling by using a scanlineDecoder. > getScanlines and skipScanlines are used for y sampling, > the swizzler is used for x sampling > > this class is currently only working for png and jpeg images > I will update other Codec types to work soon > > For SkJpegCodec to implement width wise swizzling it now > uses a swizzler. I ran performance tests on this change. > Here are the performance test results: > https://docs.google.com/a/google.com/spreadsheets/d/1D7-Q_GXD_dI68LZO005NNvb8Wq2Ee0wEBEPG72671yw/edit?usp=sharing > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/0944100ac89f797714eeae0cf2875e2335ff52ee TBR=scroggo@google.com,msarett@google.com,djsollen@google.com,mtklein@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1294593002
* SkScaledCodec classGravatar emmaleer2015-08-13
| | | | | | | | | | | | | | | | | | This class does scaling by using a scanlineDecoder. getScanlines and skipScanlines are used for y sampling, the swizzler is used for x sampling this class is currently only working for png and jpeg images I will update other Codec types to work soon For SkJpegCodec to implement width wise swizzling it now uses a swizzler. I ran performance tests on this change. Here are the performance test results: https://docs.google.com/a/google.com/spreadsheets/d/1D7-Q_GXD_dI68LZO005NNvb8Wq2Ee0wEBEPG72671yw/edit?usp=sharing BUG=skia: Review URL: https://codereview.chromium.org/1260673002
* Update CodexTest to test valid_alpha.Gravatar scroggo2015-08-12
| | | | | | | | | | | | | Add a static function to CodexTest, which consolidates decoding, comparing to an expected SkCodec::Result, and optionally comparing to a digest. Test decoding non-opaque to opaque (fails) and premul to unpremul/vice versa (succeeds). BUG=skia:3475 Review URL: https://codereview.chromium.org/1277253003
* Fix bmp RLE "bug"Gravatar msarett2015-08-12
| | | | | | | | | | | | | | | | | Chromium's test suite contains an RLE image that reports a certain file size in the header, but then contains additional encoded data. Our bmp decoder would only decode half of the image, before stopping. With this fix, we check for additional data before returning kIncompleteInput. If this lands, I will upload the test image to the bots. Also adding an invalid image test to CodexTest. BUG=skia: Review URL: https://codereview.chromium.org/1273853004
* 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
* Switching Skia to chromium's libjpeg-turboGravatar msarett2015-08-11
| | | | | | | | | | | Compile SkJpegCodec and SkImageDecoder_libjpeg with chromium's libjpeg-turbo. SkImageDecoder_libjpeg still uses libjpeg on Android and the Android framework. SkJpegCodec is still not compiled on the Android framework. BUG=skia: Review URL: https://codereview.chromium.org/1275773004
* Split SkBmpCodec into three separate classesGravatar msarett2015-08-06
| | | | | | | | | | | | | | Will regress behavior on gold on test32bfv4.bmp, where we will no longer fix transparent decodes. TODO: Start fixing transparent decodes again, or decide that we don't want to fix them and remove isTransparent from SkSwizzler. I think this may become more clear when I start implementing the scanline decoder. BUG=skia: Review URL: https://codereview.chromium.org/1258863008
* Let SkWebpCodec decode to 565Gravatar scroggo2015-08-06
| | | | | | BUG=skia:3257 Review URL: https://codereview.chromium.org/1277893002
* Support decoding PNG to 565.Gravatar scroggo2015-08-06
| | | | | | | | | | | | | | | | | | | | | | | | | Although we initially discussed not supporting 565, SkCodec needs to support Android's BitmapFactory and BitmapRegionDecoder, which need to support 565. We could instead implement 565 on top of SkCodec, but this would require more memory and run more slowly. An open question is whether to support dithering, and how. In order to support dithering, we need to pass y to RowProc, which I believe means we will need to pass y to SkSwizzler::swizzle(). I dislike having an option which is typically ignored - SkImageDecoder allows you to turn on dithering when decoding to any color type, but it is only meaningful only if the output color type is 565. We could also make the client implement dithering, which I believe would mean forcing them to do the conversion to 565 (since we have already thrown away data when we convered to 565 without dithering). BUG=skia:3257 Review URL: https://codereview.chromium.org/1277593002
* Fix ASAN error for wbmp swizzlesGravatar msarett2015-08-05
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1269413006
* 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
* Rename SkCodec_libbmp to SkBmpCodecGravatar msarett2015-07-30
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1254963006
* Make SkSwizzler::Fill() support 565Gravatar msarett2015-07-29
| | | | | | BUG=skia:4135 Review URL: https://codereview.chromium.org/1267543002
* Pass the destination pointer to next() in SkSwizzlerGravatar msarett2015-07-27
| | | | | | | | | | | Per our discussion, we can make the swizzler simpler and more usable for SkCodec and SkScanlineDecoder by only having a single version of next() which takes a pointer to the srcRow and a pointer to the dstRow. BUG=skia: Review URL: https://codereview.chromium.org/1256373002
* Remove sk_memcpy32Gravatar mtklein2015-07-27
| | | | | | | | | | | | | | | | | | | | | | | | It's only implemented on x86, where the exisiting benchmark says memcpy() is faster for all cases: Timer overhead: 24ns curr/maxrss loops min median mean max stddev samples config bench 10/10 MB 1 35.9µs 36.2µs 36.2µs 36.6µs 1% ▁▂▄▅▅▃█▄▄▅ nonrendering sk_memcpy32_100000 10/10 MB 13 2.27µs 2.28µs 2.28µs 2.29µs 0% █▄▃▅▃▁▃▅▁▄ nonrendering sk_memcpy32_10000 11/11 MB 677 91.6ns 95.9ns 94.5ns 99.4ns 3% ▅▅▅▅▅█▁▁▁▁ nonrendering sk_memcpy32_1000 11/11 MB 1171 20ns 20.9ns 21.3ns 23.4ns 6% ▁▁▇▃▃▃█▇▃▃ nonrendering sk_memcpy32_100 11/11 MB 1952 14ns 14ns 14.3ns 15.2ns 3% ▁▁██▁▁▁▁▁▁ nonrendering sk_memcpy32_10 11/11 MB 5 33.6µs 33.7µs 34.1µs 35.2µs 2% ▆▇█▁▁▁▁▁▁▁ nonrendering memcpy32_memcpy_100000 11/11 MB 18 2.12µs 2.22µs 2.24µs 2.39µs 5% ▂█▄▇█▄▇▁▁▁ nonrendering memcpy32_memcpy_10000 11/11 MB 1112 87.3ns 87.3ns 89.1ns 93.7ns 3% ▄██▄▁▁▁▁▁▁ nonrendering memcpy32_memcpy_1000 11/11 MB 2124 12.8ns 13.3ns 13.5ns 14.8ns 6% ▁▁▁█▃▃█▇▃▃ nonrendering memcpy32_memcpy_100 11/11 MB 3077 9ns 9.41ns 9.52ns 10.2ns 4% ▃█▁█▃▃▃▃▃▃ nonrendering memcpy32_memcpy_10 (Why? One fewer thing to port to SkOpts.) BUG=skia:4117 Review URL: https://codereview.chromium.org/1256763003
* 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
* removing png_read_end from SkPngScanlineDecoderGravatar emmaleer2015-07-20
| | | | | | BUG=skia:4041 Review URL: https://codereview.chromium.org/1242423002
* 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
* Changing name of has_transpareny_in_palette to has_transparency_in_tRNSGravatar emmaleer2015-07-10
| | | | | | | | | | | | This function checks for transparency info in the tRNS chunk Other images besides paletted images can have tRNS chunks, including Gray8 and RGB has_transparency_in_tRNS is a better name for the function BUG=skia: Review URL: https://codereview.chromium.org/1224453002
* 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
* Add libjpeg-turbo library (depends on yasm)Gravatar msarett2015-07-07
| | | | | | | | | | | | | | | | | | Mangle external function names to avoid conflict with libjpeg Take advantage of direct color conversion (RGBA, BGRA, 565) Prepare to use jpeg_skip_scanlines (when it is upstreamed) BUG=skia: Committed: https://skia.googlesource.com/skia/+/b60c3f8291529303299262dba19b1a896060bd2d Committed: https://skia.googlesource.com/skia/+/f8bf9181d7b0463c8e371755cfbb9ece90b34fc5 Committed: https://skia.googlesource.com/skia/+/e9e3ee33f30c14c31afd5fc3fe4dda7f15783c75 Committed: https://skia.googlesource.com/skia/+/40141b57f061fbfcc2fa38da942d9efe25aca4d0 Review URL: https://codereview.chromium.org/1180983002
* Revert of Revert of Fixing libpng transform use (patchset #1 id:1 of ↵Gravatar scroggo2015-07-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1213743004/) Reason for revert: This appears to have been reverted in order to fix the DEPS roll in https://codereview.chromium.org/1214943004/ However, it only affects SkCodec, which is not used by Chromium. Relanding Original issue's description: > Revert of Fixing libpng transform use (patchset #5 id:80001 of https://codereview.chromium.org/1214203005/) > > Reason for revert: > DEPS roll failing > > Original issue's description: > > This change: > > - supports kGray correctly > > - avoid extra call to png_get_IHDR by storing the bit depth > > - call transforms as needed > > - checks for tRNS alpha value in RGB and GRAY color types > > > > > > BUG=skia: > > > > Committed: https://skia.googlesource.com/skia/+/9693037fd41b7ce545b44beaa3489dcfd915018c > > TBR=scroggo@google.com,msarett@google.com,emmaleer@google.com > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/6c90e09575c1a77aee060aa475fdb3d25a17d6a0 TBR=msarett@google.com,emmaleer@google.com,jvanverth@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1215853005
* Revert of Switch SkJpegCode to libjpeg-turbo (patchset #29 id:750001 of ↵Gravatar jvanverth2015-07-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1180983002/) Reason for revert: DEPS roll failing Original issue's description: > Add libjpeg-turbo library (depends on yasm) > Mangle external function names to avoid conflict with libjpeg > Take advantage of direct color conversion (RGBA, BGRA, 565) > Prepare to use jpeg_skip_scanlines (when it is upstreamed) > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/b60c3f8291529303299262dba19b1a896060bd2d > > Committed: https://skia.googlesource.com/skia/+/f8bf9181d7b0463c8e371755cfbb9ece90b34fc5 > > Committed: https://skia.googlesource.com/skia/+/e9e3ee33f30c14c31afd5fc3fe4dda7f15783c75 > > Committed: https://skia.googlesource.com/skia/+/40141b57f061fbfcc2fa38da942d9efe25aca4d0 TBR=scroggo@google.com,djsollen@google.com,emmaleer@google.com,msarett@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1226543003
* Revert of Fixing libpng transform use (patchset #5 id:80001 of ↵Gravatar jvanverth2015-07-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1214203005/) Reason for revert: DEPS roll failing Original issue's description: > This change: > - supports kGray correctly > - avoid extra call to png_get_IHDR by storing the bit depth > - call transforms as needed > - checks for tRNS alpha value in RGB and GRAY color types > > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/9693037fd41b7ce545b44beaa3489dcfd915018c TBR=scroggo@google.com,msarett@google.com,emmaleer@google.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1213743004
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-16 12:17:15 +0000