gm self-test: make all test cases exercise transparency

gm self-test: make all test cases exercise transparency
BUG=https://code.google.com/p/skia/issues/detail?id=1142
Committed: https://code.google.com/p/skia/source/detail?r=7943

[epoger, 2013-03-01 17:24:52]

first LG wins

https://codereview.chromium.org/12379047/diff/1/gm/tests/outputs/compared-aga...
File
gm/tests/outputs/compared-against-different-pixels-images/output-expected/json-summary.txt
(right):

https://codereview.chromium.org/12379047/diff/1/gm/tests/outputs/compared-aga...
gm/tests/outputs/compared-against-different-pixels-images/output-expected/json-summary.txt:5:
"checksum" : 9512553915271796906
Aside: you can see that the checksums are now DIFFERENT for the 8888 and 565
representations, because the more subtle color values are rounded differently
for 8888 and 565.

https://codereview.chromium.org/12379047/diff/1/gm/tests/run.sh
File gm/tests/run.sh (left):

https://codereview.chromium.org/12379047/diff/1/gm/tests/run.sh#oldcode160
gm/tests/run.sh:160: # This test would have caught
Not needed anymore, because the "selftest" tests now exercise partially
transparent images.  And they are far simpler than aaclip, meaning that their
results should be unchanged across platforms and revisions.

[epoger, 2013-03-01 17:27:54]

P.S. Since I can't run a try job on the housekeeping bot, I did the next best
thing: I ran the gm self-test with this patch on both Mac and Linux, and it
succeeded on both.

[borenet, 2013-03-01 18:15:02]

LGTM

https://codereview.chromium.org/12379047/diff/1/gm/tests/outputs/compared-aga...
File
gm/tests/outputs/compared-against-different-pixels-images/output-expected/json-summary.txt
(right):

https://codereview.chromium.org/12379047/diff/1/gm/tests/outputs/compared-aga...
gm/tests/outputs/compared-against-different-pixels-images/output-expected/json-summary.txt:5:
"checksum" : 9512553915271796906
On 2013/03/01 17:24:52, epoger wrote:
> Aside: you can see that the checksums are now DIFFERENT for the 8888 and 565
> representations, because the more subtle color values are rounded differently
> for 8888 and 565. 

Seems like a high potential for confusion here...

[epoger, 2013-03-01 18:26:09]

https://codereview.chromium.org/12379047/diff/1/gm/tests/outputs/compared-aga...
File
gm/tests/outputs/compared-against-different-pixels-images/output-expected/json-summary.txt
(right):

https://codereview.chromium.org/12379047/diff/1/gm/tests/outputs/compared-aga...
gm/tests/outputs/compared-against-different-pixels-images/output-expected/json-summary.txt:5:
"checksum" : 9512553915271796906
On 2013/03/01 18:15:02, borenet wrote:
> On 2013/03/01 17:24:52, epoger wrote:
> > Aside: you can see that the checksums are now DIFFERENT for the 8888 and 565
> > representations, because the more subtle color values are rounded
differently
> > for 8888 and 565. 
> 
> Seems like a high potential for confusion here...

If you say so, then by definition yes. :-)

Do you have any *particular* concerns (or, even better, suggestions)?  Given
that the checksums are based on pixel values, I actually think it's fine for
them to match or not match across 8888/565 depending on whether the color is
identical at each pixel.

If I am in the minority on that point, we could explicitly distinguish between
them, maybe by adding some prefix like this:
 pixels-8888-11071285354315388429
 pixels-565-14022967492765711532
which could leave the door open for PDF to be handled like this:
 bits-222222222222222

Personally, my leaning is to handle non-pixel items by specifying a different
type of checksum, like this, and allow 8888 and 565 checksums to be
interchangeable like they are now:

"expected-results" : {
  "565/selftest1" : {
    "pixel-cityhash" : [ 11071285354315388429 ],
    "ignore-failure" : false,
  },
  "8888/selftest1" : {
    "pixel-cityhash" : [ 14022967492765711532 ],
    "ignore-failure" : false,
  },
  "pdf/selftest1" : {
    "bitwise-cityhash" : [ 222222222222222 ],
    "ignore-failure" : false,
  },
}

[borenet, 2013-03-01 19:32:42]

https://codereview.chromium.org/12379047/diff/1/gm/tests/outputs/compared-aga...
File
gm/tests/outputs/compared-against-different-pixels-images/output-expected/json-summary.txt
(right):

https://codereview.chromium.org/12379047/diff/1/gm/tests/outputs/compared-aga...
gm/tests/outputs/compared-against-different-pixels-images/output-expected/json-summary.txt:5:
"checksum" : 9512553915271796906
On 2013/03/01 18:26:09, epoger wrote:
> On 2013/03/01 18:15:02, borenet wrote:
> > On 2013/03/01 17:24:52, epoger wrote:
> > > Aside: you can see that the checksums are now DIFFERENT for the 8888 and
565
> > > representations, because the more subtle color values are rounded
> differently
> > > for 8888 and 565. 
> > 
> > Seems like a high potential for confusion here...
> 
> If you say so, then by definition yes. :-)
> 
> Do you have any *particular* concerns (or, even better, suggestions)?  Given
> that the checksums are based on pixel values, I actually think it's fine for
> them to match or not match across 8888/565 depending on whether the color is
> identical at each pixel.
> 
> If I am in the minority on that point, we could explicitly distinguish between
> them, maybe by adding some prefix like this:
>  pixels-8888-11071285354315388429
>  pixels-565-14022967492765711532
> which could leave the door open for PDF to be handled like this:
>  bits-222222222222222
> 
> Personally, my leaning is to handle non-pixel items by specifying a different
> type of checksum, like this, and allow 8888 and 565 checksums to be
> interchangeable like they are now:
> 
> "expected-results" : {
>   "565/selftest1" : {
>     "pixel-cityhash" : [ 11071285354315388429 ],
>     "ignore-failure" : false,
>   },
>   "8888/selftest1" : {
>     "pixel-cityhash" : [ 14022967492765711532 ],
>     "ignore-failure" : false,
>   },
>   "pdf/selftest1" : {
>     "bitwise-cityhash" : [ 222222222222222 ],
>     "ignore-failure" : false,
>   },
> }

I just want to make sure that there aren't any cases where we'd have problems
when we expect one format and get another.  I guess I don't have a specific
example, although I'm thinking about the files getting downloaded from GS for
comparison, and maybe about whether we can or should assume that any two files
with the same checksum are entirely interchangeable, even if they have different
bits.

[epoger, 2013-03-02 19:56:27]

Committed patchset #1 manually as r7943 (presubmit successful).