2013-10-18 20:52:44 +00:00
|
|
|
#include "DMWriteTask.h"
|
|
|
|
|
|
|
|
#include "DMUtil.h"
|
2014-01-15 21:28:25 +00:00
|
|
|
#include "SkColorPriv.h"
|
2013-10-18 20:52:44 +00:00
|
|
|
#include "SkCommandLineFlags.h"
|
|
|
|
#include "SkImageEncoder.h"
|
2014-03-05 15:37:11 +00:00
|
|
|
#include "SkMallocPixelRef.h"
|
DM: fix -w/-r problems stemming from PM/UPM conversions.
DM will now read and write a custom image format, which begins first with a
normal PNG, but also includes the bitmap's raw pixels. Most tools (file
browser, Preview, Chrome, Skia image decoder) will read the file as PNG. DM
skips the encoded PNG and reads the raw pixels instead.
This scheme allows perfect pixel comparisons that never go through PM -> UPM or
UPM -> PM conversions, as long as you compare on a machine with the same native
pixel format as the machine which generated the images. Since we've only ever
used this to do same-machine comparisons, that's more than good enough for now.
We could convert as needed to a standardized PM pixel format if we find we want
these files to be portable.
DM -w output now does increase to ~1.3G. If that turns out to be annoyingly
big, I'm sure I can come up with a simple pixelwise RLE instead of writing
uncompressed pixels.
BUG=skia:
R=reed@google.com, bsalomon@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/185343002
git-svn-id: http://skia.googlecode.com/svn/trunk@13638 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-03-03 15:43:56 +00:00
|
|
|
#include "SkStream.h"
|
2014-03-05 15:37:11 +00:00
|
|
|
#include "SkString.h"
|
2013-10-18 20:52:44 +00:00
|
|
|
|
|
|
|
DEFINE_string2(writePath, w, "", "If set, write GMs here as .pngs.");
|
2014-05-14 20:26:00 +00:00
|
|
|
DEFINE_bool(writePngOnly, false, "If true, don't encode raw bitmap after .png data. "
|
|
|
|
"This means -r won't work, but skdiff will still work fine.");
|
2013-10-18 20:52:44 +00:00
|
|
|
|
|
|
|
namespace DM {
|
|
|
|
|
Add support for reading a directory of images with --expectations (-r).
DM writes out its images in a hierarchy that's a little different than GM,
so this can't read GM's output. But it can read its own, written with -w.
Example usage:
$ out/Release/dm -w /tmp/baseline
$ out/Release/dm -r /tmp/baseline -w /tmp/new
(and optionally)
$ mkdir /tmp/diff; out/Release/skdiff /tmp/baseline /tmp/new /tmp/diff
GM's IndividualImageExpectationsSource and Expectations are a little too eager
about decoding and hashing the expected images, so I took the opportunity to
add DM::Expectations that mostly replaces skiagm::ExpectationsSource and
skiagm::Expectations in DM. It mainly exists to move the image decoding and
comparison off the main thread, which would otherwise be a major speed
bottleneck.
I tried to use skiagm code where possible. One notable place where I differed
is in this new feature. When -r is a directory of images, DM does no hashing.
It considerably faster to read the expected file into an SkBitmap and do a
byte-for-byte comparison than to hash the two bitmaps and check those.
The example usage above isn't quite working 100% yet. Expectations on some GMs
fail, even with no binary change. I haven't pinned down whether this is due to
- a bug in DM
- flaky GMs
- unthreadsafe GMs
- flaky image decoding
- unthreadsafe image decoding
- something else
but I intend to. Leon, Derek and I have suspected PNG decoding isn't
threadsafe, but are as yet unable to prove it.
I also seem to be able to cause malloc to fail on my laptop if I run too many
configs at once, though I never seem to be using more than ~1G of RAM. Will
track that down too.
BUG=
R=reed@google.com, bsalomon@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/108963002
git-svn-id: http://skia.googlecode.com/svn/trunk@12596 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-12-10 14:53:16 +00:00
|
|
|
// Splits off the last N suffixes of name (splitting on _) and appends them to out.
|
|
|
|
// Returns the total number of characters consumed.
|
|
|
|
static int split_suffixes(int N, const char* name, SkTArray<SkString>* out) {
|
2013-12-02 13:50:38 +00:00
|
|
|
SkTArray<SkString> split;
|
|
|
|
SkStrSplit(name, "_", &split);
|
Add support for reading a directory of images with --expectations (-r).
DM writes out its images in a hierarchy that's a little different than GM,
so this can't read GM's output. But it can read its own, written with -w.
Example usage:
$ out/Release/dm -w /tmp/baseline
$ out/Release/dm -r /tmp/baseline -w /tmp/new
(and optionally)
$ mkdir /tmp/diff; out/Release/skdiff /tmp/baseline /tmp/new /tmp/diff
GM's IndividualImageExpectationsSource and Expectations are a little too eager
about decoding and hashing the expected images, so I took the opportunity to
add DM::Expectations that mostly replaces skiagm::ExpectationsSource and
skiagm::Expectations in DM. It mainly exists to move the image decoding and
comparison off the main thread, which would otherwise be a major speed
bottleneck.
I tried to use skiagm code where possible. One notable place where I differed
is in this new feature. When -r is a directory of images, DM does no hashing.
It considerably faster to read the expected file into an SkBitmap and do a
byte-for-byte comparison than to hash the two bitmaps and check those.
The example usage above isn't quite working 100% yet. Expectations on some GMs
fail, even with no binary change. I haven't pinned down whether this is due to
- a bug in DM
- flaky GMs
- unthreadsafe GMs
- flaky image decoding
- unthreadsafe image decoding
- something else
but I intend to. Leon, Derek and I have suspected PNG decoding isn't
threadsafe, but are as yet unable to prove it.
I also seem to be able to cause malloc to fail on my laptop if I run too many
configs at once, though I never seem to be using more than ~1G of RAM. Will
track that down too.
BUG=
R=reed@google.com, bsalomon@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/108963002
git-svn-id: http://skia.googlecode.com/svn/trunk@12596 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-12-10 14:53:16 +00:00
|
|
|
int consumed = 0;
|
|
|
|
for (int i = 0; i < N; i++) {
|
2013-12-02 13:50:38 +00:00
|
|
|
// We're splitting off suffixes from the back to front.
|
Add support for reading a directory of images with --expectations (-r).
DM writes out its images in a hierarchy that's a little different than GM,
so this can't read GM's output. But it can read its own, written with -w.
Example usage:
$ out/Release/dm -w /tmp/baseline
$ out/Release/dm -r /tmp/baseline -w /tmp/new
(and optionally)
$ mkdir /tmp/diff; out/Release/skdiff /tmp/baseline /tmp/new /tmp/diff
GM's IndividualImageExpectationsSource and Expectations are a little too eager
about decoding and hashing the expected images, so I took the opportunity to
add DM::Expectations that mostly replaces skiagm::ExpectationsSource and
skiagm::Expectations in DM. It mainly exists to move the image decoding and
comparison off the main thread, which would otherwise be a major speed
bottleneck.
I tried to use skiagm code where possible. One notable place where I differed
is in this new feature. When -r is a directory of images, DM does no hashing.
It considerably faster to read the expected file into an SkBitmap and do a
byte-for-byte comparison than to hash the two bitmaps and check those.
The example usage above isn't quite working 100% yet. Expectations on some GMs
fail, even with no binary change. I haven't pinned down whether this is due to
- a bug in DM
- flaky GMs
- unthreadsafe GMs
- flaky image decoding
- unthreadsafe image decoding
- something else
but I intend to. Leon, Derek and I have suspected PNG decoding isn't
threadsafe, but are as yet unable to prove it.
I also seem to be able to cause malloc to fail on my laptop if I run too many
configs at once, though I never seem to be using more than ~1G of RAM. Will
track that down too.
BUG=
R=reed@google.com, bsalomon@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/108963002
git-svn-id: http://skia.googlecode.com/svn/trunk@12596 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-12-10 14:53:16 +00:00
|
|
|
out->push_back(split[split.count()-i-1]);
|
|
|
|
consumed += out->back().size() + 1; // Add one for the _.
|
2013-12-02 13:50:38 +00:00
|
|
|
}
|
Add support for reading a directory of images with --expectations (-r).
DM writes out its images in a hierarchy that's a little different than GM,
so this can't read GM's output. But it can read its own, written with -w.
Example usage:
$ out/Release/dm -w /tmp/baseline
$ out/Release/dm -r /tmp/baseline -w /tmp/new
(and optionally)
$ mkdir /tmp/diff; out/Release/skdiff /tmp/baseline /tmp/new /tmp/diff
GM's IndividualImageExpectationsSource and Expectations are a little too eager
about decoding and hashing the expected images, so I took the opportunity to
add DM::Expectations that mostly replaces skiagm::ExpectationsSource and
skiagm::Expectations in DM. It mainly exists to move the image decoding and
comparison off the main thread, which would otherwise be a major speed
bottleneck.
I tried to use skiagm code where possible. One notable place where I differed
is in this new feature. When -r is a directory of images, DM does no hashing.
It considerably faster to read the expected file into an SkBitmap and do a
byte-for-byte comparison than to hash the two bitmaps and check those.
The example usage above isn't quite working 100% yet. Expectations on some GMs
fail, even with no binary change. I haven't pinned down whether this is due to
- a bug in DM
- flaky GMs
- unthreadsafe GMs
- flaky image decoding
- unthreadsafe image decoding
- something else
but I intend to. Leon, Derek and I have suspected PNG decoding isn't
threadsafe, but are as yet unable to prove it.
I also seem to be able to cause malloc to fail on my laptop if I run too many
configs at once, though I never seem to be using more than ~1G of RAM. Will
track that down too.
BUG=
R=reed@google.com, bsalomon@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/108963002
git-svn-id: http://skia.googlecode.com/svn/trunk@12596 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-12-10 14:53:16 +00:00
|
|
|
return consumed;
|
|
|
|
}
|
|
|
|
|
2014-06-03 20:57:14 +00:00
|
|
|
inline static SkString find_gm_name(const Task& parent, SkTArray<SkString>* suffixList) {
|
2014-05-14 20:26:00 +00:00
|
|
|
const int suffixes = parent.depth() + 1;
|
|
|
|
const SkString& name = parent.name();
|
2014-06-03 20:57:14 +00:00
|
|
|
const int totalSuffixLength = split_suffixes(suffixes, name.c_str(), suffixList);
|
|
|
|
return SkString(name.c_str(), name.size() - totalSuffixLength);
|
2013-12-02 13:50:38 +00:00
|
|
|
}
|
2013-10-18 20:52:44 +00:00
|
|
|
|
2014-06-03 20:57:14 +00:00
|
|
|
WriteTask::WriteTask(const Task& parent, SkBitmap bitmap)
|
|
|
|
: CpuTask(parent)
|
|
|
|
, fGmName(find_gm_name(parent, &fSuffixes))
|
|
|
|
, fBitmap(bitmap)
|
|
|
|
, fData(NULL)
|
|
|
|
, fExtension(".png") {}
|
|
|
|
|
|
|
|
WriteTask::WriteTask(const Task& parent, SkData *data, const char* ext)
|
|
|
|
: CpuTask(parent)
|
|
|
|
, fGmName(find_gm_name(parent, &fSuffixes))
|
|
|
|
, fData(SkRef(data))
|
|
|
|
, fExtension(ext) {}
|
|
|
|
|
2013-12-02 13:50:38 +00:00
|
|
|
void WriteTask::makeDirOrFail(SkString dir) {
|
|
|
|
if (!sk_mkdir(dir.c_str())) {
|
|
|
|
this->fail();
|
|
|
|
}
|
2013-10-18 20:52:44 +00:00
|
|
|
}
|
|
|
|
|
2014-03-05 15:37:11 +00:00
|
|
|
namespace {
|
|
|
|
|
DM: fix -w/-r problems stemming from PM/UPM conversions.
DM will now read and write a custom image format, which begins first with a
normal PNG, but also includes the bitmap's raw pixels. Most tools (file
browser, Preview, Chrome, Skia image decoder) will read the file as PNG. DM
skips the encoded PNG and reads the raw pixels instead.
This scheme allows perfect pixel comparisons that never go through PM -> UPM or
UPM -> PM conversions, as long as you compare on a machine with the same native
pixel format as the machine which generated the images. Since we've only ever
used this to do same-machine comparisons, that's more than good enough for now.
We could convert as needed to a standardized PM pixel format if we find we want
these files to be portable.
DM -w output now does increase to ~1.3G. If that turns out to be annoyingly
big, I'm sure I can come up with a simple pixelwise RLE instead of writing
uncompressed pixels.
BUG=skia:
R=reed@google.com, bsalomon@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/185343002
git-svn-id: http://skia.googlecode.com/svn/trunk@13638 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-03-03 15:43:56 +00:00
|
|
|
// One file that first contains a .png of an SkBitmap, then its raw pixels.
|
|
|
|
// We use this custom format to avoid premultiplied/unpremultiplied pixel conversions.
|
|
|
|
struct PngAndRaw {
|
|
|
|
static bool Encode(SkBitmap bitmap, const char* path) {
|
|
|
|
SkFILEWStream stream(path);
|
|
|
|
if (!stream.isValid()) {
|
|
|
|
SkDebugf("Can't write %s.\n", path);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Write a PNG first for humans and other tools to look at.
|
|
|
|
if (!SkImageEncoder::EncodeStream(&stream, bitmap, SkImageEncoder::kPNG_Type, 100)) {
|
|
|
|
SkDebugf("Can't encode a PNG.\n");
|
|
|
|
return false;
|
|
|
|
}
|
2014-05-14 20:26:00 +00:00
|
|
|
if (FLAGS_writePngOnly) {
|
|
|
|
return true;
|
|
|
|
}
|
DM: fix -w/-r problems stemming from PM/UPM conversions.
DM will now read and write a custom image format, which begins first with a
normal PNG, but also includes the bitmap's raw pixels. Most tools (file
browser, Preview, Chrome, Skia image decoder) will read the file as PNG. DM
skips the encoded PNG and reads the raw pixels instead.
This scheme allows perfect pixel comparisons that never go through PM -> UPM or
UPM -> PM conversions, as long as you compare on a machine with the same native
pixel format as the machine which generated the images. Since we've only ever
used this to do same-machine comparisons, that's more than good enough for now.
We could convert as needed to a standardized PM pixel format if we find we want
these files to be portable.
DM -w output now does increase to ~1.3G. If that turns out to be annoyingly
big, I'm sure I can come up with a simple pixelwise RLE instead of writing
uncompressed pixels.
BUG=skia:
R=reed@google.com, bsalomon@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/185343002
git-svn-id: http://skia.googlecode.com/svn/trunk@13638 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-03-03 15:43:56 +00:00
|
|
|
|
2014-03-05 15:37:11 +00:00
|
|
|
// Pad out so the raw pixels start 4-byte aligned.
|
|
|
|
const uint32_t maxPadding = 0;
|
|
|
|
const size_t pos = stream.bytesWritten();
|
|
|
|
stream.write(&maxPadding, SkAlign4(pos) - pos);
|
|
|
|
|
DM: fix -w/-r problems stemming from PM/UPM conversions.
DM will now read and write a custom image format, which begins first with a
normal PNG, but also includes the bitmap's raw pixels. Most tools (file
browser, Preview, Chrome, Skia image decoder) will read the file as PNG. DM
skips the encoded PNG and reads the raw pixels instead.
This scheme allows perfect pixel comparisons that never go through PM -> UPM or
UPM -> PM conversions, as long as you compare on a machine with the same native
pixel format as the machine which generated the images. Since we've only ever
used this to do same-machine comparisons, that's more than good enough for now.
We could convert as needed to a standardized PM pixel format if we find we want
these files to be portable.
DM -w output now does increase to ~1.3G. If that turns out to be annoyingly
big, I'm sure I can come up with a simple pixelwise RLE instead of writing
uncompressed pixels.
BUG=skia:
R=reed@google.com, bsalomon@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/185343002
git-svn-id: http://skia.googlecode.com/svn/trunk@13638 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-03-03 15:43:56 +00:00
|
|
|
// Then write our secret raw pixels that only DM reads.
|
|
|
|
SkAutoLockPixels lock(bitmap);
|
|
|
|
return stream.write(bitmap.getPixels(), bitmap.getSize());
|
|
|
|
}
|
|
|
|
|
|
|
|
// This assumes bitmap already has allocated pixels of the correct size.
|
2014-03-05 15:37:11 +00:00
|
|
|
static bool Decode(const char* path, SkImageInfo info, SkBitmap* bitmap) {
|
|
|
|
SkAutoTUnref<SkData> data(SkData::NewFromFileName(path));
|
|
|
|
if (!data) {
|
DM: fix -w/-r problems stemming from PM/UPM conversions.
DM will now read and write a custom image format, which begins first with a
normal PNG, but also includes the bitmap's raw pixels. Most tools (file
browser, Preview, Chrome, Skia image decoder) will read the file as PNG. DM
skips the encoded PNG and reads the raw pixels instead.
This scheme allows perfect pixel comparisons that never go through PM -> UPM or
UPM -> PM conversions, as long as you compare on a machine with the same native
pixel format as the machine which generated the images. Since we've only ever
used this to do same-machine comparisons, that's more than good enough for now.
We could convert as needed to a standardized PM pixel format if we find we want
these files to be portable.
DM -w output now does increase to ~1.3G. If that turns out to be annoyingly
big, I'm sure I can come up with a simple pixelwise RLE instead of writing
uncompressed pixels.
BUG=skia:
R=reed@google.com, bsalomon@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/185343002
git-svn-id: http://skia.googlecode.com/svn/trunk@13638 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-03-03 15:43:56 +00:00
|
|
|
SkDebugf("Can't read %s.\n", path);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-03-05 15:37:11 +00:00
|
|
|
// The raw pixels are at the end of the file. We'll skip the encoded PNG at the front.
|
|
|
|
const size_t rowBytes = info.minRowBytes(); // Assume densely packed.
|
|
|
|
const size_t bitmapBytes = info.getSafeSize(rowBytes);
|
|
|
|
if (data->size() < bitmapBytes) {
|
DM: fix -w/-r problems stemming from PM/UPM conversions.
DM will now read and write a custom image format, which begins first with a
normal PNG, but also includes the bitmap's raw pixels. Most tools (file
browser, Preview, Chrome, Skia image decoder) will read the file as PNG. DM
skips the encoded PNG and reads the raw pixels instead.
This scheme allows perfect pixel comparisons that never go through PM -> UPM or
UPM -> PM conversions, as long as you compare on a machine with the same native
pixel format as the machine which generated the images. Since we've only ever
used this to do same-machine comparisons, that's more than good enough for now.
We could convert as needed to a standardized PM pixel format if we find we want
these files to be portable.
DM -w output now does increase to ~1.3G. If that turns out to be annoyingly
big, I'm sure I can come up with a simple pixelwise RLE instead of writing
uncompressed pixels.
BUG=skia:
R=reed@google.com, bsalomon@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/185343002
git-svn-id: http://skia.googlecode.com/svn/trunk@13638 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-03-03 15:43:56 +00:00
|
|
|
SkDebugf("%s is too small to contain the bitmap we're looking for.\n", path);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-03-05 15:37:11 +00:00
|
|
|
const size_t offset = data->size() - bitmapBytes;
|
2014-04-21 21:08:14 +00:00
|
|
|
SkAutoTUnref<SkData> subset(
|
|
|
|
SkData::NewSubset(data, offset, bitmapBytes));
|
2014-03-05 15:37:11 +00:00
|
|
|
SkAutoTUnref<SkPixelRef> pixels(
|
2014-04-21 21:08:14 +00:00
|
|
|
SkMallocPixelRef::NewWithData(
|
|
|
|
info, rowBytes, NULL/*ctable*/, subset));
|
2014-03-05 15:37:11 +00:00
|
|
|
SkASSERT(pixels);
|
|
|
|
|
2014-05-30 13:26:10 +00:00
|
|
|
bitmap->setInfo(info, rowBytes);
|
2014-03-05 15:37:11 +00:00
|
|
|
bitmap->setPixelRef(pixels);
|
DM: fix -w/-r problems stemming from PM/UPM conversions.
DM will now read and write a custom image format, which begins first with a
normal PNG, but also includes the bitmap's raw pixels. Most tools (file
browser, Preview, Chrome, Skia image decoder) will read the file as PNG. DM
skips the encoded PNG and reads the raw pixels instead.
This scheme allows perfect pixel comparisons that never go through PM -> UPM or
UPM -> PM conversions, as long as you compare on a machine with the same native
pixel format as the machine which generated the images. Since we've only ever
used this to do same-machine comparisons, that's more than good enough for now.
We could convert as needed to a standardized PM pixel format if we find we want
these files to be portable.
DM -w output now does increase to ~1.3G. If that turns out to be annoyingly
big, I'm sure I can come up with a simple pixelwise RLE instead of writing
uncompressed pixels.
BUG=skia:
R=reed@google.com, bsalomon@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/185343002
git-svn-id: http://skia.googlecode.com/svn/trunk@13638 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-03-03 15:43:56 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2014-06-03 20:57:14 +00:00
|
|
|
// Does not take ownership of data.
|
|
|
|
bool save_data_to_file(const SkData* data, const char* path) {
|
|
|
|
SkFILEWStream stream(path);
|
|
|
|
if (!stream.isValid() || !stream.write(data->data(), data->size())) {
|
|
|
|
SkDebugf("Can't write %s.\n", path);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-03-05 15:37:11 +00:00
|
|
|
} // namespace
|
|
|
|
|
2013-10-18 20:52:44 +00:00
|
|
|
void WriteTask::draw() {
|
2013-12-02 13:50:38 +00:00
|
|
|
SkString dir(FLAGS_writePath[0]);
|
|
|
|
this->makeDirOrFail(dir);
|
|
|
|
for (int i = 0; i < fSuffixes.count(); i++) {
|
|
|
|
dir = SkOSPath::SkPathJoin(dir.c_str(), fSuffixes[i].c_str());
|
|
|
|
this->makeDirOrFail(dir);
|
|
|
|
}
|
2014-06-03 20:57:14 +00:00
|
|
|
|
Add support for reading a directory of images with --expectations (-r).
DM writes out its images in a hierarchy that's a little different than GM,
so this can't read GM's output. But it can read its own, written with -w.
Example usage:
$ out/Release/dm -w /tmp/baseline
$ out/Release/dm -r /tmp/baseline -w /tmp/new
(and optionally)
$ mkdir /tmp/diff; out/Release/skdiff /tmp/baseline /tmp/new /tmp/diff
GM's IndividualImageExpectationsSource and Expectations are a little too eager
about decoding and hashing the expected images, so I took the opportunity to
add DM::Expectations that mostly replaces skiagm::ExpectationsSource and
skiagm::Expectations in DM. It mainly exists to move the image decoding and
comparison off the main thread, which would otherwise be a major speed
bottleneck.
I tried to use skiagm code where possible. One notable place where I differed
is in this new feature. When -r is a directory of images, DM does no hashing.
It considerably faster to read the expected file into an SkBitmap and do a
byte-for-byte comparison than to hash the two bitmaps and check those.
The example usage above isn't quite working 100% yet. Expectations on some GMs
fail, even with no binary change. I haven't pinned down whether this is due to
- a bug in DM
- flaky GMs
- unthreadsafe GMs
- flaky image decoding
- unthreadsafe image decoding
- something else
but I intend to. Leon, Derek and I have suspected PNG decoding isn't
threadsafe, but are as yet unable to prove it.
I also seem to be able to cause malloc to fail on my laptop if I run too many
configs at once, though I never seem to be using more than ~1G of RAM. Will
track that down too.
BUG=
R=reed@google.com, bsalomon@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/108963002
git-svn-id: http://skia.googlecode.com/svn/trunk@12596 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-12-10 14:53:16 +00:00
|
|
|
SkString path = SkOSPath::SkPathJoin(dir.c_str(), fGmName.c_str());
|
2014-06-03 20:57:14 +00:00
|
|
|
path.append(fExtension);
|
|
|
|
|
|
|
|
const bool ok = fData.get() ? save_data_to_file(fData, path.c_str())
|
|
|
|
: PngAndRaw::Encode(fBitmap, path.c_str());
|
|
|
|
if (!ok) {
|
2013-10-18 20:52:44 +00:00
|
|
|
this->fail();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
SkString WriteTask::name() const {
|
2013-12-02 13:50:38 +00:00
|
|
|
SkString name("writing ");
|
|
|
|
for (int i = 0; i < fSuffixes.count(); i++) {
|
|
|
|
name.appendf("%s/", fSuffixes[i].c_str());
|
|
|
|
}
|
|
|
|
name.append(fGmName.c_str());
|
|
|
|
return name;
|
2013-10-18 20:52:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool WriteTask::shouldSkip() const {
|
|
|
|
return FLAGS_writePath.isEmpty();
|
|
|
|
}
|
|
|
|
|
Add support for reading a directory of images with --expectations (-r).
DM writes out its images in a hierarchy that's a little different than GM,
so this can't read GM's output. But it can read its own, written with -w.
Example usage:
$ out/Release/dm -w /tmp/baseline
$ out/Release/dm -r /tmp/baseline -w /tmp/new
(and optionally)
$ mkdir /tmp/diff; out/Release/skdiff /tmp/baseline /tmp/new /tmp/diff
GM's IndividualImageExpectationsSource and Expectations are a little too eager
about decoding and hashing the expected images, so I took the opportunity to
add DM::Expectations that mostly replaces skiagm::ExpectationsSource and
skiagm::Expectations in DM. It mainly exists to move the image decoding and
comparison off the main thread, which would otherwise be a major speed
bottleneck.
I tried to use skiagm code where possible. One notable place where I differed
is in this new feature. When -r is a directory of images, DM does no hashing.
It considerably faster to read the expected file into an SkBitmap and do a
byte-for-byte comparison than to hash the two bitmaps and check those.
The example usage above isn't quite working 100% yet. Expectations on some GMs
fail, even with no binary change. I haven't pinned down whether this is due to
- a bug in DM
- flaky GMs
- unthreadsafe GMs
- flaky image decoding
- unthreadsafe image decoding
- something else
but I intend to. Leon, Derek and I have suspected PNG decoding isn't
threadsafe, but are as yet unable to prove it.
I also seem to be able to cause malloc to fail on my laptop if I run too many
configs at once, though I never seem to be using more than ~1G of RAM. Will
track that down too.
BUG=
R=reed@google.com, bsalomon@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/108963002
git-svn-id: http://skia.googlecode.com/svn/trunk@12596 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-12-10 14:53:16 +00:00
|
|
|
static SkString path_to_expected_image(const char* root, const Task& task) {
|
|
|
|
SkString filename = task.name();
|
|
|
|
|
|
|
|
// We know that all names passed in here belong to top-level Tasks, which have a single suffix
|
|
|
|
// (8888, 565, gpu, etc.) indicating what subdirectory to look in.
|
|
|
|
SkTArray<SkString> suffixes;
|
|
|
|
const int suffixLength = split_suffixes(1, filename.c_str(), &suffixes);
|
|
|
|
SkASSERT(1 == suffixes.count());
|
|
|
|
|
|
|
|
// We'll look in root/suffix for images.
|
|
|
|
const SkString dir = SkOSPath::SkPathJoin(root, suffixes[0].c_str());
|
|
|
|
|
|
|
|
// Remove the suffix and tack on a .png.
|
|
|
|
filename.remove(filename.size() - suffixLength, suffixLength);
|
|
|
|
filename.append(".png");
|
|
|
|
|
|
|
|
return SkOSPath::SkPathJoin(dir.c_str(), filename.c_str());
|
|
|
|
}
|
|
|
|
|
|
|
|
bool WriteTask::Expectations::check(const Task& task, SkBitmap bitmap) const {
|
2014-02-10 16:39:40 +00:00
|
|
|
if (!FLAGS_writePath.isEmpty() && 0 == strcmp(FLAGS_writePath[0], fRoot)) {
|
|
|
|
SkDebugf("We seem to be reading and writing %s concurrently. This won't work.\n", fRoot);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
Add support for reading a directory of images with --expectations (-r).
DM writes out its images in a hierarchy that's a little different than GM,
so this can't read GM's output. But it can read its own, written with -w.
Example usage:
$ out/Release/dm -w /tmp/baseline
$ out/Release/dm -r /tmp/baseline -w /tmp/new
(and optionally)
$ mkdir /tmp/diff; out/Release/skdiff /tmp/baseline /tmp/new /tmp/diff
GM's IndividualImageExpectationsSource and Expectations are a little too eager
about decoding and hashing the expected images, so I took the opportunity to
add DM::Expectations that mostly replaces skiagm::ExpectationsSource and
skiagm::Expectations in DM. It mainly exists to move the image decoding and
comparison off the main thread, which would otherwise be a major speed
bottleneck.
I tried to use skiagm code where possible. One notable place where I differed
is in this new feature. When -r is a directory of images, DM does no hashing.
It considerably faster to read the expected file into an SkBitmap and do a
byte-for-byte comparison than to hash the two bitmaps and check those.
The example usage above isn't quite working 100% yet. Expectations on some GMs
fail, even with no binary change. I haven't pinned down whether this is due to
- a bug in DM
- flaky GMs
- unthreadsafe GMs
- flaky image decoding
- unthreadsafe image decoding
- something else
but I intend to. Leon, Derek and I have suspected PNG decoding isn't
threadsafe, but are as yet unable to prove it.
I also seem to be able to cause malloc to fail on my laptop if I run too many
configs at once, though I never seem to be using more than ~1G of RAM. Will
track that down too.
BUG=
R=reed@google.com, bsalomon@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/108963002
git-svn-id: http://skia.googlecode.com/svn/trunk@12596 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-12-10 14:53:16 +00:00
|
|
|
const SkString path = path_to_expected_image(fRoot, task);
|
|
|
|
SkBitmap expected;
|
2014-03-05 15:37:11 +00:00
|
|
|
if (!PngAndRaw::Decode(path.c_str(), bitmap.info(), &expected)) {
|
2014-01-06 20:24:21 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return BitmapsEqual(expected, bitmap);
|
Add support for reading a directory of images with --expectations (-r).
DM writes out its images in a hierarchy that's a little different than GM,
so this can't read GM's output. But it can read its own, written with -w.
Example usage:
$ out/Release/dm -w /tmp/baseline
$ out/Release/dm -r /tmp/baseline -w /tmp/new
(and optionally)
$ mkdir /tmp/diff; out/Release/skdiff /tmp/baseline /tmp/new /tmp/diff
GM's IndividualImageExpectationsSource and Expectations are a little too eager
about decoding and hashing the expected images, so I took the opportunity to
add DM::Expectations that mostly replaces skiagm::ExpectationsSource and
skiagm::Expectations in DM. It mainly exists to move the image decoding and
comparison off the main thread, which would otherwise be a major speed
bottleneck.
I tried to use skiagm code where possible. One notable place where I differed
is in this new feature. When -r is a directory of images, DM does no hashing.
It considerably faster to read the expected file into an SkBitmap and do a
byte-for-byte comparison than to hash the two bitmaps and check those.
The example usage above isn't quite working 100% yet. Expectations on some GMs
fail, even with no binary change. I haven't pinned down whether this is due to
- a bug in DM
- flaky GMs
- unthreadsafe GMs
- flaky image decoding
- unthreadsafe image decoding
- something else
but I intend to. Leon, Derek and I have suspected PNG decoding isn't
threadsafe, but are as yet unable to prove it.
I also seem to be able to cause malloc to fail on my laptop if I run too many
configs at once, though I never seem to be using more than ~1G of RAM. Will
track that down too.
BUG=
R=reed@google.com, bsalomon@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/108963002
git-svn-id: http://skia.googlecode.com/svn/trunk@12596 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-12-10 14:53:16 +00:00
|
|
|
}
|
|
|
|
|
2013-10-18 20:52:44 +00:00
|
|
|
} // namespace DM
|