2013-10-16 13:02:15 +00:00
|
|
|
#include "DMCpuTask.h"
|
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
|
|
|
#include "DMExpectationsTask.h"
|
2013-10-28 19:51:26 +00:00
|
|
|
#include "DMPipeTask.h"
|
2013-10-16 13:02:15 +00:00
|
|
|
#include "DMReplayTask.h"
|
2013-10-21 18:40:25 +00:00
|
|
|
#include "DMSerializeTask.h"
|
2013-12-02 13:50:38 +00:00
|
|
|
#include "DMTileGridTask.h"
|
2013-10-16 13:02:15 +00:00
|
|
|
#include "DMUtil.h"
|
2013-10-18 20:52:44 +00:00
|
|
|
#include "DMWriteTask.h"
|
2013-10-16 13:02:15 +00:00
|
|
|
|
|
|
|
namespace DM {
|
|
|
|
|
2014-02-26 23:01:57 +00:00
|
|
|
CpuTask::CpuTask(const char* config,
|
2013-10-16 13:02:15 +00:00
|
|
|
Reporter* reporter,
|
|
|
|
TaskRunner* taskRunner,
|
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 Expectations& expectations,
|
2013-10-16 13:02:15 +00:00
|
|
|
skiagm::GMRegistry::Factory gmFactory,
|
2014-02-16 00:59:25 +00:00
|
|
|
SkColorType colorType)
|
2013-10-16 13:02:15 +00:00
|
|
|
: Task(reporter, taskRunner)
|
|
|
|
, fGMFactory(gmFactory)
|
|
|
|
, fGM(fGMFactory(NULL))
|
2014-02-26 23:01:57 +00:00
|
|
|
, fName(UnderJoin(fGM->getName(), config))
|
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
|
|
|
, fExpectations(expectations)
|
2014-02-16 00:59:25 +00:00
|
|
|
, fColorType(colorType)
|
2013-10-16 13:02:15 +00:00
|
|
|
{}
|
|
|
|
|
|
|
|
void CpuTask::draw() {
|
|
|
|
SkBitmap bitmap;
|
2014-02-16 00:59:25 +00:00
|
|
|
SetupBitmap(fColorType, fGM.get(), &bitmap);
|
2013-10-16 13:02:15 +00:00
|
|
|
|
2013-10-21 18:40:25 +00:00
|
|
|
SkCanvas canvas(bitmap);
|
2013-10-16 13:02:15 +00:00
|
|
|
canvas.concat(fGM->getInitialTransform());
|
|
|
|
fGM->draw(&canvas);
|
|
|
|
canvas.flush();
|
|
|
|
|
2013-12-02 13:50:38 +00:00
|
|
|
#define SPAWN(ChildTask, ...) this->spawnChild(SkNEW_ARGS(ChildTask, (*this, __VA_ARGS__)))
|
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
|
|
|
SPAWN(ExpectationsTask, fExpectations, bitmap);
|
2013-11-26 18:52:31 +00:00
|
|
|
|
2013-12-02 13:50:38 +00:00
|
|
|
SPAWN(PipeTask, fGMFactory(NULL), bitmap, false, false);
|
|
|
|
SPAWN(PipeTask, fGMFactory(NULL), bitmap, true, false);
|
|
|
|
SPAWN(PipeTask, fGMFactory(NULL), bitmap, true, true);
|
|
|
|
SPAWN(ReplayTask, fGMFactory(NULL), bitmap, false);
|
|
|
|
SPAWN(ReplayTask, fGMFactory(NULL), bitmap, true);
|
|
|
|
SPAWN(SerializeTask, fGMFactory(NULL), bitmap);
|
|
|
|
SPAWN(TileGridTask, fGMFactory(NULL), bitmap, SkISize::Make(16,16));
|
2013-10-30 20:45:28 +00:00
|
|
|
|
2013-12-02 13:50:38 +00:00
|
|
|
SPAWN(WriteTask, bitmap);
|
|
|
|
#undef SPAWN
|
2013-10-16 13:02:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool CpuTask::shouldSkip() const {
|
2014-02-16 00:59:25 +00:00
|
|
|
if (kRGB_565_SkColorType == fColorType && (fGM->getFlags() & skiagm::GM::kSkip565_Flag)) {
|
2013-10-16 13:02:15 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (fGM->getFlags() & skiagm::GM::kGPUOnly_Flag) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace DM
|