2015-03-27 19:16:53 +00:00
|
|
|
/*
|
|
|
|
* Copyright 2015 Google Inc.
|
|
|
|
*
|
|
|
|
* Use of this source code is governed by a BSD-style license that can be
|
|
|
|
* found in the LICENSE file.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "Resources.h"
|
|
|
|
#include "SkBitmap.h"
|
|
|
|
#include "SkCodec.h"
|
|
|
|
#include "SkMD5.h"
|
SkCodec no longer inherits from SkImageGenerator.
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
2015-07-09 15:16:03 +00:00
|
|
|
#include "SkScanlineDecoder.h"
|
2015-03-27 19:16:53 +00:00
|
|
|
#include "Test.h"
|
|
|
|
|
|
|
|
static SkStreamAsset* resource(const char path[]) {
|
|
|
|
SkString fullPath = GetResourcePath(path);
|
|
|
|
return SkStream::NewFromFile(fullPath.c_str());
|
|
|
|
}
|
|
|
|
|
|
|
|
static void md5(const SkBitmap& bm, SkMD5::Digest* digest) {
|
|
|
|
SkAutoLockPixels autoLockPixels(bm);
|
|
|
|
SkASSERT(bm.getPixels());
|
|
|
|
SkMD5 md5;
|
|
|
|
size_t rowLen = bm.info().bytesPerPixel() * bm.width();
|
|
|
|
for (int y = 0; y < bm.height(); ++y) {
|
|
|
|
md5.update(static_cast<uint8_t*>(bm.getAddr(0, y)), rowLen);
|
|
|
|
}
|
|
|
|
md5.finish(*digest);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void check(skiatest::Reporter* r,
|
|
|
|
const char path[],
|
|
|
|
SkISize size,
|
2015-04-01 18:25:20 +00:00
|
|
|
bool supportsScanlineDecoding) {
|
2015-03-27 19:16:53 +00:00
|
|
|
SkAutoTDelete<SkStream> stream(resource(path));
|
|
|
|
if (!stream) {
|
|
|
|
SkDebugf("Missing resource '%s'\n", path);
|
|
|
|
return;
|
|
|
|
}
|
2015-04-01 18:25:20 +00:00
|
|
|
SkAutoTDelete<SkCodec> codec(SkCodec::NewFromStream(stream.detach()));
|
|
|
|
if (!codec) {
|
2015-03-27 19:16:53 +00:00
|
|
|
ERRORF(r, "Unable to decode '%s'", path);
|
|
|
|
return;
|
|
|
|
}
|
2015-04-09 19:43:10 +00:00
|
|
|
|
|
|
|
// This test is used primarily to verify rewinding works properly. Using kN32 allows
|
|
|
|
// us to test this without the added overhead of creating different bitmaps depending
|
|
|
|
// on the color type (ex: building a color table for kIndex8). DM is where we test
|
|
|
|
// decodes to all possible destination color types.
|
|
|
|
SkImageInfo info = codec->getInfo().makeColorType(kN32_SkColorType);
|
2015-03-27 19:16:53 +00:00
|
|
|
REPORTER_ASSERT(r, info.dimensions() == size);
|
|
|
|
SkBitmap bm;
|
|
|
|
bm.allocPixels(info);
|
|
|
|
SkAutoLockPixels autoLockPixels(bm);
|
SkCodec no longer inherits from SkImageGenerator.
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
2015-07-09 15:16:03 +00:00
|
|
|
SkCodec::Result result =
|
2015-04-01 18:25:20 +00:00
|
|
|
codec->getPixels(info, bm.getPixels(), bm.rowBytes(), NULL, NULL, NULL);
|
SkCodec no longer inherits from SkImageGenerator.
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
2015-07-09 15:16:03 +00:00
|
|
|
REPORTER_ASSERT(r, result == SkCodec::kSuccess);
|
2015-03-27 19:16:53 +00:00
|
|
|
|
|
|
|
SkMD5::Digest digest1, digest2;
|
|
|
|
md5(bm, &digest1);
|
|
|
|
|
|
|
|
bm.eraseColor(SK_ColorYELLOW);
|
|
|
|
|
|
|
|
result =
|
2015-04-01 18:25:20 +00:00
|
|
|
codec->getPixels(info, bm.getPixels(), bm.rowBytes(), NULL, NULL, NULL);
|
2015-03-27 19:16:53 +00:00
|
|
|
|
SkCodec no longer inherits from SkImageGenerator.
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
2015-07-09 15:16:03 +00:00
|
|
|
REPORTER_ASSERT(r, result == SkCodec::kSuccess);
|
2015-04-01 18:25:20 +00:00
|
|
|
// verify that re-decoding gives the same result.
|
|
|
|
md5(bm, &digest2);
|
|
|
|
REPORTER_ASSERT(r, digest1 == digest2);
|
|
|
|
|
|
|
|
SkScanlineDecoder* scanlineDecoder = codec->getScanlineDecoder(info);
|
|
|
|
if (supportsScanlineDecoding) {
|
|
|
|
bm.eraseColor(SK_ColorYELLOW);
|
|
|
|
REPORTER_ASSERT(r, scanlineDecoder);
|
2015-07-01 13:50:35 +00:00
|
|
|
|
|
|
|
// Regular decodes should be disabled after creating a scanline decoder
|
|
|
|
result = codec->getPixels(info, bm.getPixels(), bm.rowBytes(), NULL, NULL, NULL);
|
SkCodec no longer inherits from SkImageGenerator.
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
2015-07-09 15:16:03 +00:00
|
|
|
REPORTER_ASSERT(r, SkCodec::kInvalidParameters == result);
|
2015-04-01 18:25:20 +00:00
|
|
|
for (int y = 0; y < info.height(); y++) {
|
|
|
|
result = scanlineDecoder->getScanlines(bm.getAddr(0, y), 1, 0);
|
SkCodec no longer inherits from SkImageGenerator.
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
2015-07-09 15:16:03 +00:00
|
|
|
REPORTER_ASSERT(r, result == SkCodec::kSuccess);
|
2015-04-01 18:25:20 +00:00
|
|
|
}
|
|
|
|
// verify that scanline decoding gives the same result.
|
|
|
|
SkMD5::Digest digest3;
|
|
|
|
md5(bm, &digest3);
|
|
|
|
REPORTER_ASSERT(r, digest3 == digest1);
|
|
|
|
} else {
|
|
|
|
REPORTER_ASSERT(r, !scanlineDecoder);
|
2015-03-27 19:16:53 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
DEF_TEST(Codec, r) {
|
|
|
|
// WBMP
|
2015-04-01 18:25:20 +00:00
|
|
|
check(r, "mandrill.wbmp", SkISize::Make(512, 512), false);
|
2015-03-27 19:16:53 +00:00
|
|
|
|
2015-06-18 19:53:43 +00:00
|
|
|
// WEBP
|
|
|
|
check(r, "baby_tux.webp", SkISize::Make(386, 395), false);
|
|
|
|
check(r, "color_wheel.webp", SkISize::Make(128, 128), false);
|
|
|
|
check(r, "yellow_rose.webp", SkISize::Make(400, 301), false);
|
|
|
|
|
2015-03-27 19:16:53 +00:00
|
|
|
// BMP
|
2015-04-01 18:25:20 +00:00
|
|
|
check(r, "randPixels.bmp", SkISize::Make(8, 8), false);
|
2015-03-27 19:16:53 +00:00
|
|
|
|
|
|
|
// ICO
|
2015-04-01 19:09:21 +00:00
|
|
|
// These two tests examine interestingly different behavior:
|
|
|
|
// Decodes an embedded BMP image
|
2015-04-01 18:25:20 +00:00
|
|
|
check(r, "color_wheel.ico", SkISize::Make(128, 128), false);
|
2015-04-01 19:09:21 +00:00
|
|
|
// Decodes an embedded PNG image
|
|
|
|
check(r, "google_chrome.ico", SkISize::Make(256, 256), false);
|
2015-03-27 19:16:53 +00:00
|
|
|
|
2015-04-09 19:43:10 +00:00
|
|
|
// GIF
|
|
|
|
check(r, "box.gif", SkISize::Make(200, 55), false);
|
|
|
|
check(r, "color_wheel.gif", SkISize::Make(128, 128), false);
|
|
|
|
check(r, "randPixels.gif", SkISize::Make(8, 8), false);
|
|
|
|
|
2015-04-15 14:32:19 +00:00
|
|
|
// JPG
|
2015-04-29 15:17:15 +00:00
|
|
|
check(r, "CMYK.jpg", SkISize::Make(642, 516), true);
|
|
|
|
check(r, "color_wheel.jpg", SkISize::Make(128, 128), true);
|
|
|
|
check(r, "grayscale.jpg", SkISize::Make(128, 128), true);
|
|
|
|
check(r, "mandrill_512_q075.jpg", SkISize::Make(512, 512), true);
|
|
|
|
check(r, "randPixels.jpg", SkISize::Make(8, 8), true);
|
2015-04-15 14:32:19 +00:00
|
|
|
|
2015-03-27 19:16:53 +00:00
|
|
|
// PNG
|
2015-04-01 16:33:23 +00:00
|
|
|
check(r, "arrow.png", SkISize::Make(187, 312), true);
|
|
|
|
check(r, "baby_tux.png", SkISize::Make(240, 246), true);
|
|
|
|
check(r, "color_wheel.png", SkISize::Make(128, 128), true);
|
|
|
|
check(r, "half-transparent-white-pixel.png", SkISize::Make(1, 1), true);
|
|
|
|
check(r, "mandrill_128.png", SkISize::Make(128, 128), true);
|
|
|
|
check(r, "mandrill_16.png", SkISize::Make(16, 16), true);
|
|
|
|
check(r, "mandrill_256.png", SkISize::Make(256, 256), true);
|
|
|
|
check(r, "mandrill_32.png", SkISize::Make(32, 32), true);
|
|
|
|
check(r, "mandrill_512.png", SkISize::Make(512, 512), true);
|
|
|
|
check(r, "mandrill_64.png", SkISize::Make(64, 64), true);
|
|
|
|
check(r, "plane.png", SkISize::Make(250, 126), true);
|
|
|
|
check(r, "randPixels.png", SkISize::Make(8, 8), true);
|
|
|
|
check(r, "yellow_rose.png", SkISize::Make(400, 301), true);
|
2015-03-27 19:16:53 +00:00
|
|
|
}
|
2015-04-03 14:22:22 +00:00
|
|
|
|
|
|
|
static void test_invalid_stream(skiatest::Reporter* r, const void* stream, size_t len) {
|
|
|
|
SkCodec* codec = SkCodec::NewFromStream(new SkMemoryStream(stream, len, false));
|
|
|
|
// We should not have gotten a codec. Bots should catch us if we leaked anything.
|
|
|
|
REPORTER_ASSERT(r, !codec);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Ensure that SkCodec::NewFromStream handles freeing the passed in SkStream,
|
|
|
|
// even on failure. Test some bad streams.
|
|
|
|
DEF_TEST(Codec_leaks, r) {
|
|
|
|
// No codec should claim this as their format, so this tests SkCodec::NewFromStream.
|
|
|
|
const char nonSupportedStream[] = "hello world";
|
|
|
|
// The other strings should look like the beginning of a file type, so we'll call some
|
|
|
|
// internal version of NewFromStream, which must also delete the stream on failure.
|
|
|
|
const unsigned char emptyPng[] = { 0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a };
|
|
|
|
const unsigned char emptyJpeg[] = { 0xFF, 0xD8, 0xFF };
|
|
|
|
const char emptyWebp[] = "RIFF1234WEBPVP";
|
|
|
|
const char emptyBmp[] = { 'B', 'M' };
|
|
|
|
const char emptyIco[] = { '\x00', '\x00', '\x01', '\x00' };
|
|
|
|
const char emptyGif[] = "GIFVER";
|
|
|
|
|
|
|
|
test_invalid_stream(r, nonSupportedStream, sizeof(nonSupportedStream));
|
|
|
|
test_invalid_stream(r, emptyPng, sizeof(emptyPng));
|
|
|
|
test_invalid_stream(r, emptyJpeg, sizeof(emptyJpeg));
|
|
|
|
test_invalid_stream(r, emptyWebp, sizeof(emptyWebp));
|
|
|
|
test_invalid_stream(r, emptyBmp, sizeof(emptyBmp));
|
|
|
|
test_invalid_stream(r, emptyIco, sizeof(emptyIco));
|
|
|
|
test_invalid_stream(r, emptyGif, sizeof(emptyGif));
|
|
|
|
}
|
2015-04-15 14:32:19 +00:00
|
|
|
|
|
|
|
static void test_dimensions(skiatest::Reporter* r, const char path[]) {
|
|
|
|
// Create the codec from the resource file
|
|
|
|
SkAutoTDelete<SkStream> stream(resource(path));
|
|
|
|
if (!stream) {
|
|
|
|
SkDebugf("Missing resource '%s'\n", path);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
SkAutoTDelete<SkCodec> codec(SkCodec::NewFromStream(stream.detach()));
|
|
|
|
if (!codec) {
|
|
|
|
ERRORF(r, "Unable to create codec '%s'", path);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check that the decode is successful for a variety of scales
|
|
|
|
for (float scale = -0.05f; scale < 2.0f; scale += 0.05f) {
|
|
|
|
// Scale the output dimensions
|
|
|
|
SkISize scaledDims = codec->getScaledDimensions(scale);
|
|
|
|
SkImageInfo scaledInfo = codec->getInfo().makeWH(scaledDims.width(), scaledDims.height());
|
|
|
|
|
|
|
|
// Set up for the decode
|
|
|
|
size_t rowBytes = scaledDims.width() * sizeof(SkPMColor);
|
|
|
|
size_t totalBytes = scaledInfo.getSafeSize(rowBytes);
|
|
|
|
SkAutoTMalloc<SkPMColor> pixels(totalBytes);
|
|
|
|
|
SkCodec no longer inherits from SkImageGenerator.
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
2015-07-09 15:16:03 +00:00
|
|
|
SkCodec::Result result =
|
2015-04-15 14:32:19 +00:00
|
|
|
codec->getPixels(scaledInfo, pixels.get(), rowBytes, NULL, NULL, NULL);
|
SkCodec no longer inherits from SkImageGenerator.
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
2015-07-09 15:16:03 +00:00
|
|
|
REPORTER_ASSERT(r, SkCodec::kSuccess == result);
|
2015-04-15 14:32:19 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Ensure that onGetScaledDimensions returns valid image dimensions to use for decodes
|
|
|
|
DEF_TEST(Codec_Dimensions, r) {
|
|
|
|
// JPG
|
|
|
|
test_dimensions(r, "CMYK.jpg");
|
|
|
|
test_dimensions(r, "color_wheel.jpg");
|
|
|
|
test_dimensions(r, "grayscale.jpg");
|
|
|
|
test_dimensions(r, "mandrill_512_q075.jpg");
|
|
|
|
test_dimensions(r, "randPixels.jpg");
|
|
|
|
}
|
|
|
|
|
2015-04-23 15:53:39 +00:00
|
|
|
static void test_empty(skiatest::Reporter* r, const char path[]) {
|
|
|
|
SkAutoTDelete<SkStream> stream(resource(path));
|
|
|
|
if (!stream) {
|
|
|
|
SkDebugf("Missing resource '%s'\n", path);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
SkAutoTDelete<SkCodec> codec(SkCodec::NewFromStream(stream.detach()));
|
|
|
|
REPORTER_ASSERT(r, NULL == codec);
|
|
|
|
}
|
2015-04-15 14:32:19 +00:00
|
|
|
|
2015-04-23 15:53:39 +00:00
|
|
|
DEF_TEST(Codec_Empty, r) {
|
|
|
|
// Test images that should not be able to create a codec
|
|
|
|
test_empty(r, "empty_images/zero-dims.gif");
|
|
|
|
test_empty(r, "empty_images/zero-embedded.ico");
|
|
|
|
test_empty(r, "empty_images/zero-width.bmp");
|
|
|
|
test_empty(r, "empty_images/zero-height.bmp");
|
|
|
|
test_empty(r, "empty_images/zero-width.jpg");
|
|
|
|
test_empty(r, "empty_images/zero-height.jpg");
|
|
|
|
test_empty(r, "empty_images/zero-width.png");
|
|
|
|
test_empty(r, "empty_images/zero-height.png");
|
|
|
|
test_empty(r, "empty_images/zero-width.wbmp");
|
|
|
|
test_empty(r, "empty_images/zero-height.wbmp");
|
|
|
|
}
|