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);
|
|
|
|
}
|
|
|
|
|
Allow creating multiple scanline decoders.
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
2015-07-10 19:07:02 +00:00
|
|
|
/**
|
|
|
|
* Compute the digest for bm and compare it to a known good digest.
|
|
|
|
* @param r Reporter to assert that bm's digest matches goodDigest.
|
|
|
|
* @param goodDigest The known good digest to compare to.
|
|
|
|
* @param bm The bitmap to test.
|
|
|
|
*/
|
|
|
|
static void compare_to_good_digest(skiatest::Reporter* r, const SkMD5::Digest& goodDigest,
|
|
|
|
const SkBitmap& bm) {
|
|
|
|
SkMD5::Digest digest;
|
|
|
|
md5(bm, &digest);
|
|
|
|
REPORTER_ASSERT(r, digest == goodDigest);
|
|
|
|
}
|
|
|
|
|
2015-03-27 19:16:53 +00:00
|
|
|
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
|
|
|
|
Allow creating multiple scanline decoders.
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
2015-07-10 19:07:02 +00:00
|
|
|
SkMD5::Digest digest;
|
|
|
|
md5(bm, &digest);
|
2015-03-27 19:16:53 +00:00
|
|
|
|
|
|
|
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.
|
Allow creating multiple scanline decoders.
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
2015-07-10 19:07:02 +00:00
|
|
|
compare_to_good_digest(r, digest, bm);
|
2015-04-01 18:25:20 +00:00
|
|
|
|
Allow creating multiple scanline decoders.
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
2015-07-10 19:07:02 +00:00
|
|
|
SkAutoTDelete<SkScanlineDecoder> scanlineDecoder(codec->getScanlineDecoder(info));
|
2015-04-01 18:25:20 +00:00
|
|
|
if (supportsScanlineDecoding) {
|
|
|
|
bm.eraseColor(SK_ColorYELLOW);
|
|
|
|
REPORTER_ASSERT(r, scanlineDecoder);
|
2015-07-01 13:50:35 +00:00
|
|
|
|
Allow creating multiple scanline decoders.
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
2015-07-10 19:07:02 +00:00
|
|
|
// Regular decodes should not be affected by creating a scanline decoder
|
2015-07-01 13:50:35 +00:00
|
|
|
result = codec->getPixels(info, bm.getPixels(), bm.rowBytes(), NULL, NULL, NULL);
|
Allow creating multiple scanline decoders.
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
2015-07-10 19:07:02 +00:00
|
|
|
REPORTER_ASSERT(r, SkCodec::kSuccess == result);
|
|
|
|
compare_to_good_digest(r, digest, bm);
|
|
|
|
|
|
|
|
bm.eraseColor(SK_ColorYELLOW);
|
|
|
|
|
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.
|
Allow creating multiple scanline decoders.
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
2015-07-10 19:07:02 +00:00
|
|
|
compare_to_good_digest(r, digest, bm);
|
2015-04-01 18:25:20 +00:00
|
|
|
} 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");
|
|
|
|
}
|