Remove SK_SUPPORT_LEGACY_GRADIENT_DITHERING from Skia proper

Remove SK_SUPPORT_LEGACY_GRADIENT_DITHERING from Skia proper

Migrating the flag to embedder defines (Chromium already guarded).

Also augment gradient-focused GMs to generate both dithered/undithered
results.

BUG=skia:4436
R=reed@google.com,robertphillips@google.com

Committed: https://skia.googlesource.com/skia/+/063675ba374cb520fe58bbcdaf5afeea0aa0ad60

[f(malita), 2015-10-12 17:13:40]

Gradients are used extensively in GMs: I'm seeing ~120 diffs locally.

Can't think of a good way to minimize the impact because enabling dithering
explicitly on paints also yields diffs for 565 and GPU.

I'll just have to eat the fallout and triage manually.

[f(malita), 2015-10-12 17:13:47]

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

[commit-bot: I haz the power, 2015-10-12 17:14:02]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1400813006/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1400813006/1

[reed1, 2015-10-12 17:20:39]

lgtm

[commit-bot: I haz the power, 2015-10-12 17:21:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-10-12 17:21:44]

Dry run: This issue passed the CQ dry run.

[f(malita), 2015-10-12 17:40:35]

The CQ bit was checked by fmalita@chromium.org

[commit-bot: I haz the power, 2015-10-12 17:40:51]

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

[commit-bot: I haz the power, 2015-10-12 17:41:50]

Committed patchset #1 (id:1) as
https://skia.googlesource.com/skia/+/063675ba374cb520fe58bbcdaf5afeea0aa0ad60

[scroggo, 2015-10-13 13:46:42]

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

[scroggo, 2015-10-13 13:46:43]

https://codereview.chromium.org/1400813006/diff/1/gyp/skia_for_android_framew...
File gyp/skia_for_android_framework_defines.gypi (right):

https://codereview.chromium.org/1400813006/diff/1/gyp/skia_for_android_framew...
gyp/skia_for_android_framework_defines.gypi:20:
'SK_SUPPORT_LEGACY_GRADIENT_DITHERING',
Thanks for thinking about Android! What is the difference here? Does Android
need to be updated? (e.g. to use a paint with dither set)

[f(malita), 2015-10-13 14:29:26]

On 2015/10/13 13:46:43, scroggo wrote:
>
https://codereview.chromium.org/1400813006/diff/1/gyp/skia_for_android_framew...
> File gyp/skia_for_android_framework_defines.gypi (right):
> 
>
https://codereview.chromium.org/1400813006/diff/1/gyp/skia_for_android_framew...
> gyp/skia_for_android_framework_defines.gypi:20:
> 'SK_SUPPORT_LEGACY_GRADIENT_DITHERING',
> Thanks for thinking about Android! What is the difference here? Does Android
> need to be updated? (e.g. to use a paint with dither set)

Without this define, we disable dithering for gradients unless explicitly
requested on the paint (kDither_Flag).  Disabling dithering can yield
poor-looking shallow gradients (banding artifacts).

There are two Android client categories I'm concerned about:

1) internal/framework/UI - Mike mentioned the UI makes use of shallow gradients.
 These users could be updated to request explicit dithering and preserve the
current appearance.

2) external apps - since the paint, dither flag & gradients are in public Canvas
API, we can't just magically always turn on dithering under the hood (or could
we?) => if we drop the define, we may change the appearance of external apps. 
Not sure what to do about this, except document that gradients' dithering is
controlled by the paint, let it soak for a couple of releases and then make the
switch.

The compile flag is not expensive to maintain (guards exactly one line of code),
so for now it's probably OK to keep it.  But long-term we should come up with a
clear plan for the above.

[reed1, 2015-10-13 15:45:57]

I think android already tweaks what a "default" paint is (for text encoding), so
perhaps we should wack that to always set the dither-bit. Would that address
some of the concerns?

[f(malita), 2015-10-13 15:54:22]

On 2015/10/13 15:45:57, reed1 wrote:
> I think android already tweaks what a "default" paint is (for text encoding),
so
> perhaps we should wack that to always set the dither-bit. Would that address
> some of the concerns?

Yup, I think that would solve point #2.