Add GrColor4f type, store that in GrPaint. Linearize based on global flag.

GrColor4f is yet another 4f color type, unfortunately.

- Sk4f would be my choice, but it's not allowed in include/
- SkColor4f and SkPM4f are specified to be unpremultiplied/premultiplied, whereas GrColor (and GrColor4f) are either, depending on context.

This adds 12 bytes to GrPaint. Not sure if we want to pay that price. The precision loss for a single value (vs. in a gradient, etc...) may not justify changing the storage type here. Easy enough to back that part out, while still keeping the 4f intermediate type for the helper math that it adds, and for storage and parameter passing in other locations.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2088303002

Committed: https://skia.googlesource.com/skia/+/a4535a34d1b317543307df6901debfefe7132569

[Brian Osman, 2016-06-22 21:35:36]

Description was changed from

==========
Add GrColor4f, store that in GrPaint

BUG=skia:
==========

to

==========
Add GrColor4f, store that in GrPaint

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2088303002
==========

[Brian Osman, 2016-06-23 15:03:11]

Description was changed from

==========
Add GrColor4f, store that in GrPaint

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2088303002
==========

to

==========
GrColor4f is yet another 4f color type, unfortunately.

- Sk4f would be my choice, but it's not allowed in include/
- SkColor4f and SkPM4f are specified to be unpremultiplied/premultiplied,
whereas GrColor (and GrColor4f) are either, depending on context.

This adds 12 bytes to GrPaint. Not sure if we want to pay that price. The
precision loss for a single value (vs. in a gradient, etc...) may not justify
changing the storage type here. Easy enough to back that part out, while still
keeping the 4f intermediate type for the helper math that it adds, and for
storage and parameter passing in other locations.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2088303002
==========

[Brian Osman, 2016-06-23 15:09:18]

brianosman@google.com changed reviewers:
+ bsalomon@google.com, herb@google.com, mtklein@google.com, reed@google.com

[Brian Osman, 2016-06-23 15:09:19]

First (tiny) steps toward handling non-image sources in Ganesh.

[Brian Osman, 2016-06-23 15:09:41]

The CQ bit was checked by brianosman@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-06-23 15:09:52]

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

[bsalomon, 2016-06-23 15:20:30]

https://codereview.chromium.org/2088303002/diff/20001/src/gpu/SkGr.cpp
File src/gpu/SkGr.cpp (right):

https://codereview.chromium.org/2088303002/diff/20001/src/gpu/SkGr.cpp#newcod...
src/gpu/SkGr.cpp:537: extern bool gTreatSkColorAsSRGB;
What's this?

[commit-bot: I haz the power, 2016-06-23 15:27:02]

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

[commit-bot: I haz the power, 2016-06-23 15:27:03]

Dry run: This issue passed the CQ dry run.

[Brian Osman, 2016-06-23 15:51:08]

On 2016/06/23 15:20:30, bsalomon wrote:
> https://codereview.chromium.org/2088303002/diff/20001/src/gpu/SkGr.cpp
> File src/gpu/SkGr.cpp (right):
> 
>
https://codereview.chromium.org/2088303002/diff/20001/src/gpu/SkGr.cpp#newcod...
> src/gpu/SkGr.cpp:537: extern bool gTreatSkColorAsSRGB;
> What's this?

It's a hack that's currently defined in SkColor.cpp. It's used in some raster
backend helpers in that file, and in SkPM4fPriv.h, to either apply (or not) the
srgb-to-linear conversion to SkColor values. After talking to reed@, we'd like
to nail down the following:

"In non-legacy mode, untagged/raw SkColors behave as if they are a single pixel
in a JPG/PNG. That is, they are treated as being encoded with the sRGB gamma,
and in the sRGB gamut."

That stance allows us to remove that boolean entirely, and - I believe - just
use the 'allowSrgbInputs' check in this case.

[bsalomon, 2016-06-24 13:54:48]

On 2016/06/23 15:51:08, Brian Osman wrote:
> On 2016/06/23 15:20:30, bsalomon wrote:
> > https://codereview.chromium.org/2088303002/diff/20001/src/gpu/SkGr.cpp
> > File src/gpu/SkGr.cpp (right):
> > 
> >
>
https://codereview.chromium.org/2088303002/diff/20001/src/gpu/SkGr.cpp#newcod...
> > src/gpu/SkGr.cpp:537: extern bool gTreatSkColorAsSRGB;
> > What's this?
> 
> It's a hack that's currently defined in SkColor.cpp. It's used in some raster
> backend helpers in that file, and in SkPM4fPriv.h, to either apply (or not)
the
> srgb-to-linear conversion to SkColor values. After talking to reed@, we'd like
> to nail down the following:
> 
> "In non-legacy mode, untagged/raw SkColors behave as if they are a single
pixel
> in a JPG/PNG. That is, they are treated as being encoded with the sRGB gamma,
> and in the sRGB gamut."
> 
> That stance allows us to remove that boolean entirely, and - I believe - just
> use the 'allowSrgbInputs' check in this case.

sgtm, lgtm

[Brian Osman, 2016-06-24 19:33:12]

The CQ bit was checked by brianosman@google.com

[Brian Osman, 2016-06-24 19:33:12]

The patchset sent to the CQ was uploaded after l-g-t-m from bsalomon@google.com
Link to the patchset: https://codereview.chromium.org/2088303002/#ps80001
(title: "Fix conversion to SkColor4f with new channel order")

[commit-bot: I haz the power, 2016-06-24 19:33:14]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Brian Osman, 2016-06-24 19:33:21]

The CQ bit was unchecked by brianosman@google.com

[Brian Osman, 2016-06-24 19:34:46]

The CQ bit was checked by brianosman@google.com

[commit-bot: I haz the power, 2016-06-24 19:34:54]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-24 19:50:21]

Description was changed from

==========
GrColor4f is yet another 4f color type, unfortunately.

- Sk4f would be my choice, but it's not allowed in include/
- SkColor4f and SkPM4f are specified to be unpremultiplied/premultiplied,
whereas GrColor (and GrColor4f) are either, depending on context.

This adds 12 bytes to GrPaint. Not sure if we want to pay that price. The
precision loss for a single value (vs. in a gradient, etc...) may not justify
changing the storage type here. Easy enough to back that part out, while still
keeping the 4f intermediate type for the helper math that it adds, and for
storage and parameter passing in other locations.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2088303002
==========

to

==========
GrColor4f is yet another 4f color type, unfortunately.

- Sk4f would be my choice, but it's not allowed in include/
- SkColor4f and SkPM4f are specified to be unpremultiplied/premultiplied,
whereas GrColor (and GrColor4f) are either, depending on context.

This adds 12 bytes to GrPaint. Not sure if we want to pay that price. The
precision loss for a single value (vs. in a gradient, etc...) may not justify
changing the storage type here. Easy enough to back that part out, while still
keeping the 4f intermediate type for the helper math that it adds, and for
storage and parameter passing in other locations.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2088303002

Committed:
https://skia.googlesource.com/skia/+/a4535a34d1b317543307df6901debfefe7132569
==========

[commit-bot: I haz the power, 2016-06-24 19:50:22]

Committed patchset #5 (id:80001) as
https://skia.googlesource.com/skia/+/a4535a34d1b317543307df6901debfefe7132569