New baselines for all currently-failing tests. All of these are minor pixel diffs, except for dashc…

New baselines for all currently-failing tests. All of these are minor pixel diffs, except for dashcubics_gpu on Tegra, whose baseline was previously missing.

TBR=robertphillips
BUG=

Committed: https://code.google.com/p/skia/source/detail?r=12194

[Stephen White, 2013-11-08 16:47:09]

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

[epoger, 2013-11-08 16:54:05]

Thanks for updating the baselines.  A couple of questions:

1. It seems like this was done with some tool other than the new
rebaseline_server (based on the fact that certain fields did not get updated). 
Is there some particular reason for that?  (I'm trying to make rebaseline_server
be the best tool for this job)

2. Did you actually visually inspect/approve some/all of these?  I know that
http://chromium-skia-gm.commondatastorage.googleapis.com/gm/bitmap-64bitMD5/s...
, which you marked as the new expectation in
Test-Android-Xoom-Tegra2-Arm7-Debug/expected-results.json , is incorrect.  So
what about the rest?

[Stephen White, 2013-11-08 17:42:18]

On 2013/11/08 16:54:05, epoger wrote:
> Thanks for updating the baselines.  A couple of questions:
> 
> 1. It seems like this was done with some tool other than the new
> rebaseline_server (based on the fact that certain fields did not get updated).

> Is there some particular reason for that?  (I'm trying to make
rebaseline_server
> be the best tool for this job)

I used rebaseline.py and svndiff.py. I'll give the rebaseline server a try next
time.

> 2. Did you actually visually inspect/approve some/all of these?  I know that
>
http://chromium-skia-gm.commondatastorage.googleapis.com/gm/bitmap-64bitMD5/s...
> , which you marked as the new expectation in
> Test-Android-Xoom-Tegra2-Arm7-Debug/expected-results.json , is incorrect.  So
> what about the rest?

Yes, I looked at them all in svndiff.py (hacked up to get around Xoom failures).
Sorry, I just saw some differences from the previous, but now I see they're both
wrong. I see this is logged as
https://code.google.com/p/skia/issues/detail?id=1814 and marked as
ignore-failure: true. Should we just remove the bad baseline from the JSON? It
doesn't seem to make much sense to have any baseline in there, if they're all
known to be incorrect.

[epoger, 2013-11-08 17:49:00]

On 2013/11/08 17:42:18, Stephen White wrote:
> On 2013/11/08 16:54:05, epoger wrote:
> > Thanks for updating the baselines.  A couple of questions:
> > 
> > 1. It seems like this was done with some tool other than the new
> > rebaseline_server (based on the fact that certain fields did not get
updated).
> 
> > Is there some particular reason for that?  (I'm trying to make
> rebaseline_server
> > be the best tool for this job)
> 
> I used rebaseline.py and svndiff.py. I'll give the rebaseline server a try
next
> time.

No problem, I just want to make sure that rebaseline_server improves lives.  If
you have any questions/comments about using it, let me know.

> 
> > 2. Did you actually visually inspect/approve some/all of these?  I know that
> >
>
http://chromium-skia-gm.commondatastorage.googleapis.com/gm/bitmap-64bitMD5/s...
> > , which you marked as the new expectation in
> > Test-Android-Xoom-Tegra2-Arm7-Debug/expected-results.json , is incorrect. 
So
> > what about the rest?
> 
> Yes, I looked at them all in svndiff.py (hacked up to get around Xoom
failures).

Happily, with rebaseline_server you shouldn't have to do any hacking. :-)

> Sorry, I just saw some differences from the previous, but now I see they're
both
> wrong. I see this is logged as
> https://code.google.com/p/skia/issues/detail?id=1814 and marked as
> ignore-failure: true. Should we just remove the bad baseline from the JSON? It
> doesn't seem to make much sense to have any baseline in there, if they're all
> known to be incorrect.

I think it's fine as it is.  The expectation tells us what image it generated
last time, but the additional notations (especially the bug) tell us that the
image is known to be bogus.  And ignore-failure keeps it from bugging us if its
results are nondeterministic until the problem is fixed.

I just wanted to make sure that the OTHER changes (most of which are NOT marked
as ignore-failure) are actually legit.

[robertphillips, 2013-11-08 18:03:39]

I currently use the webpage/server to review the situation then use
rebaseline/svndiff to do the actual rebaselining. Without the difference
magnitude information and the difference image I don't feel I can usefully
rebaseline with the webpage/server.

[robertphillips, 2013-11-08 18:04:28]

I did use the the webpage/server when all I had to do was add a bug # to a bunch
of existing images.

[epoger, 2013-11-08 18:08:40]

On 2013/11/08 18:03:39, robertphillips wrote:
> I currently use the webpage/server to review the situation then use
> rebaseline/svndiff to do the actual rebaselining. Without the difference
> magnitude information and the difference image I don't feel I can usefully
> rebaseline with the webpage/server.

Makes perfect sense to me, Robert, thanks for the info.

Again I have happy news to report: I committed the fix for that shortcoming
TODAY.   You can see it in action at
http://wpgntat-ubiq141.hot.corp.google.com:6823/static/view.html?resultsToLoa...

If there are additional tweaks to those pixel diffs that would be helpful, let
me know!  I'll be working with Derek to integrate perceptual-diff metrics soon.