skia2/dm/DMExpectationsTask.cpp

#include "DMExpectationsTask.h"
#include "DMUtil.h"

namespace DM {

ExpectationsTask::ExpectationsTask(const Task& parent,
                                   const Expectations& expectations,
                                   SkBitmap bitmap)
    : CpuTask(parent)
    , fName(parent.name())  // Masquerade as parent so failures are attributed to it.
    , fExpectations(expectations)
    , fBitmap(bitmap)
    {}

void ExpectationsTask::draw() {
    if (!fExpectations.check(*this, fBitmap)) {
        this->fail();
    }
}

}  // 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			`#include "DMExpectationsTask.h"`
			`#include "DMUtil.h"`

			`namespace DM {`

			`ExpectationsTask::ExpectationsTask(const Task& parent,`
			`const Expectations& expectations,`
			`SkBitmap bitmap)`
DM: make GPU tasks multithreaded again. Big refactor. The main meat of things is in SkThreadPool. We can now give SkThreadPool a type for each thread to create and destroy on its local stack. It's TLS without going through SkTLS. I've split the DM tasks into CpuTasks that run on threads with no TLS, and GpuTasks that run on threads with a thread local GrContextFactory. The old CpuTask and GpuTask have been renamed to CpuGMTask and GpuGMTask. Upshot: default run of out/Debug/dm goes from ~45 seconds to ~20 seconds. BUG=skia: R=bsalomon@google.com, mtklein@google.com, reed@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/179233005 git-svn-id: http://skia.googlecode.com/svn/trunk@13632 2bbb7eff-a529-9590-31e7-b0007b416f81 2014-02-28 20:31:31 +00:00			`: CpuTask(parent)`
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			`, fName(parent.name()) // Masquerade as parent so failures are attributed to it.`
			`, fExpectations(expectations)`
			`, fBitmap(bitmap)`
			`{}`

			`void ExpectationsTask::draw() {`
			`if (!fExpectations.check(*this, fBitmap)) {`
			`this->fail();`
			`}`
			`}`

			`} // namespace DM`