We've already decoded the PNGs themselves into unpremultiplied bitmaps with native byte order. SkColor is just not the right choice unless you get lucky.
dm -w /tmp/dm && dm -r /tmp/dm still works on Linux, and it's much closer to working on Mac:
0 tasks left, 2 failed
Failures:
matrixconvolution_gpu
colormatrix_gpu
BUG=skia:
R=reed@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/139943002
git-svn-id: http://skia.googlecode.com/svn/trunk@13101 2bbb7eff-a529-9590-31e7-b0007b416f81
PNGs store unpremultiplied colors, so we have to convert back and forth with
SkBitmap. This is lossy. GM solves this problem by stripping the alpha
channel before writing the PNG.
This flips it around, converting the GM's output to unpremultiplied as needed. This way each pixel goes from premul to unpremul once, never back.
Tested:
out/Release/dm -w /tmp/w --config 565 8888 gpu
out/Release/dm -r /tmp/w --config 565 8888 gpu
BUG=
R=bsalomon@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/122923003
git-svn-id: http://skia.googlecode.com/svn/trunk@12926 2bbb7eff-a529-9590-31e7-b0007b416f81
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
This is sort of the near-minimal proof-of-concept skeleton.
- It can run existing GMs.
- It supports most configs (just not PDF).
- --replay is the only "fancy" feature it currently supports
Hopefully you will be disturbed by its speed.
BUG=
R=epoger@google.com
Review URL: https://codereview.chromium.org/22839016
git-svn-id: http://skia.googlecode.com/svn/trunk@11802 2bbb7eff-a529-9590-31e7-b0007b416f81
