remove SK_SUPPORT_LEGACY_INT_COLORMATRIX flag

remove SK_SUPPORT_LEGACY_INT_COLORMATRIX flag

BUG=

[reed2, 2015-03-24 01:20:08]

The CQ bit was checked by reed@chromium.org

[commit-bot: I haz the power, 2015-03-24 01:20:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1032593003/1

[reed2, 2015-03-24 01:21:57]

The CQ bit was unchecked by reed@chromium.org

[reed2, 2015-03-28 00:00:17]

reed@chromium.org changed reviewers:
+ fmalita@chromium.org, mtklein@google.com

[reed2, 2015-03-28 00:00:18]

this is to enable the 2x-3x faster colormatrixfilter code (using Sk4f)

[mtklein_C, 2015-03-28 00:53:41]

mtklein@chromium.org changed reviewers:
+ mtklein@chromium.org

[mtklein_C, 2015-03-28 00:53:42]

lgtm

[reed2, 2015-03-28 01:03:53]

I think we'll need to do some layout-suppressioning ...

[mtklein, 2015-03-28 01:05:50]

On 2015/03/28 01:03:53, reed2 wrote:
> I think we'll need to do some layout-suppressioning ...

Oh dear.  Does this create a side-by-side or something for us to look at?

[reed2, 2015-03-28 08:06:21]

https://storage.googleapis.com/chromium-layout-test-archives/linux_blink_rel/...

[f(malita), 2015-03-28 21:54:55]

On 2015/03/28 08:06:21, reed2 wrote:
>
https://storage.googleapis.com/chromium-layout-test-archives/linux_blink_rel/...

I also see three related crashes in there:

[4:4:0327/175203:5585734195:INFO:SkColorMatrixFilter.cpp(264)]
../../third_party/skia/src/effects/SkColorMatrixFilter.cpp:264: failed assertion
"pmf.isValid()"

[4:4:0327/175203:5585734477:FATAL:SkColorMatrixFilter.cpp(264)] SK_CRASH

[reed2, 2015-03-31 01:34:05]

The CQ bit was checked by reed@chromium.org to run a CQ dry run

[reed2, 2015-03-31 01:34:30]

retrying now that potential fix landed in skia (and has rolled into chrome)

[commit-bot: I haz the power, 2015-03-31 01:34:59]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1032593003/20001

[reed2, 2015-03-31 01:36:00]

The CQ bit was unchecked by reed@chromium.org

[f(malita), 2015-03-31 17:41:57]

On 2015/03/31 01:34:59, I haz the power (commit-bot) wrote:
> CQ is trying da patch. Follow status at
>  https://chromium-cq-status.appspot.com/patch-status/1032593003/20001

The layout diffs look ok, but there are also some cc "unittest" failures:
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...

I've dealt with those before - they do a fuzzy comparison against a checked-in
reference image which presumably needs updating. I'll fork this CL and upload
suppressions/baselines.

[f(malita), 2015-03-31 19:48:31]

On 2015/03/31 17:41:57, f(malita) wrote:
> On 2015/03/31 01:34:59, I haz the power (commit-bot) wrote:
> > CQ is trying da patch. Follow status at
> >  https://chromium-cq-status.appspot.com/patch-status/1032593003/20001
> 
> The layout diffs look ok, but there are also some cc "unittest" failures:
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...
> 
> I've dealt with those before - they do a fuzzy comparison against a checked-in
> reference image which presumably needs updating. I'll fork this CL and upload
> suppressions/baselines.

Actually, looking at the failing tests they use an exact pixel comparator. The
problem is the software impl results are now off-by-one in some cases vs. the gl
results => they can no longer share the same reference result.

Are the differences in software vs. GL color matrix expected/acceptable?

If yes, I guess we could change the tests to use a fuzzy comparator instead.

[f(malita), 2015-03-31 20:08:05]

On 2015/03/31 19:48:31, f(malita) wrote:
> On 2015/03/31 17:41:57, f(malita) wrote:
> > On 2015/03/31 01:34:59, I haz the power (commit-bot) wrote:
> > > CQ is trying da patch. Follow status at
> > >  https://chromium-cq-status.appspot.com/patch-status/1032593003/20001
> > 
> > The layout diffs look ok, but there are also some cc "unittest" failures:
> >
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...
> > 
> > I've dealt with those before - they do a fuzzy comparison against a
checked-in
> > reference image which presumably needs updating. I'll fork this CL and
upload
> > suppressions/baselines.
> 
> Actually, looking at the failing tests they use an exact pixel comparator. The
> problem is the software impl results are now off-by-one in some cases vs. the
gl
> results => they can no longer share the same reference result.
> 
> Are the differences in software vs. GL color matrix expected/acceptable?
> 
> If yes, I guess we could change the tests to use a fuzzy comparator instead.

Previous/expected result: http://i.imgur.com/eBy2Kvs.png
New result: http://i.imgur.com/8hbj1uJ.png

Looks like we lost full opacity (alpha is 254), which may be a bug.

[reed1, 2015-04-07 18:18:11]

reed@google.com changed reviewers:
+ reed@google.com

[reed1, 2015-04-07 18:18:12]

ah, definitely a bug

[reed1, 2015-04-07 20:56:25]

... assuming I can find the smoking gun. Its "possible" that the resulting diff
alpha is a 2nd-order difference, since we know that existing xfermodes (not
related to this cl) can lose opaqueness. If the new colorfilter, when operating
on a non-opaque color, returned diff values than the old colorfilter, this could
in turn trigger a resulting alpha difference.

[mtklein, 2015-04-21 15:31:44]

mtklein@google.com changed reviewers:
- mtklein@chromium.org, mtklein@google.com