Gamma-correctness pushed into Skia, top-down.

SkSurfaceProps now has a gamma-correct ("AllowSRGBInputs") flag. That's propagated in a few places so that the backend can do the right thing for L32 vs S32 mode.

Also added SkSurfaceProps to SkSpecialImage, so that Image -> Surface conversion can preserve the desired behavior during filtering.

Many small changes, including a bunch of comments about places where we may be losing information right now. My approach was to ensure that if anything fails, it will always fall back to "legacy" mode - gamma-correctness is opt-in, so I'll just have to feed things through as missing cases are exposed.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1838953007

Committed: https://skia.googlesource.com/skia/+/898235c4864df66aa7f6d32bc2a8b8551040ce1e

[Brian Osman, 2016-03-31 20:00:04]

Description was changed from

==========
Pushing SkSurfaceProps into render target, turns into a mess.


Blargh. No SkSurfaceProps from within the GPU or RenderTarget?


Add getter for SkSurfaceProps, and AllowSRGBInputs flag.

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...

patch from issue 1838953007 at patchset 1 (http://crrev.com/1838953007#ps1)
==========

to

==========
SkSurfaceProps now has a gamma-correct ("AllowSRGBInputs") flag. That's
propagated in a few places so that the backend can do the right thing for L32 vs
S32 mode.

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

[Brian Osman, 2016-04-04 20:12:51]

Description was changed from

==========
SkSurfaceProps now has a gamma-correct ("AllowSRGBInputs") flag. That's
propagated in a few places so that the backend can do the right thing for L32 vs
S32 mode.

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

to

==========
SkSurfaceProps now has a gamma-correct ("AllowSRGBInputs") flag. That's
propagated in a few places so that the backend can do the right thing for L32 vs
S32 mode.

Also added SkSurfaceProps to SkSpecialImage, so that Image -> Surface conversion
can preserve the desired behavior during filtering.

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

[Brian Osman, 2016-04-04 20:14:19]

Description was changed from

==========
SkSurfaceProps now has a gamma-correct ("AllowSRGBInputs") flag. That's
propagated in a few places so that the backend can do the right thing for L32 vs
S32 mode.

Also added SkSurfaceProps to SkSpecialImage, so that Image -> Surface conversion
can preserve the desired behavior during filtering.

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

to

==========
SkSurfaceProps now has a gamma-correct ("AllowSRGBInputs") flag. That's
propagated in a few places so that the backend can do the right thing for L32 vs
S32 mode.

Also added SkSurfaceProps to SkSpecialImage, so that Image -> Surface conversion
can preserve the desired behavior during filtering.

Many small changes, including a bunch of comments about places where we may be
losing information right now. My approach was to ensure that if anything fails,
it will always fall back to "legacy" mode - gamma-correctness is opt-in, so I'll
just have to feed things through as missing cases are exposed.
BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

[Brian Osman, 2016-04-04 20:14:35]

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

[commit-bot: I haz the power, 2016-04-04 20:14:44]

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

[Brian Osman, 2016-04-04 20:28:21]

brianosman@google.com changed reviewers:
+ bsalomon@google.com, robertphillips@google.com

[Brian Osman, 2016-04-04 20:28:22]

There are obviously still gaps, but all GMs produce the same results in gpusrgb
config that they did previously (when the decode flag was always set based on
the destination render target config).

[commit-bot: I haz the power, 2016-04-04 20:30:33]

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

[commit-bot: I haz the power, 2016-04-04 20:30:34]

Dry run: This issue passed the CQ dry run.

[reed1, 2016-04-04 21:12:28]

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

[reed1, 2016-04-04 21:12:30]

https://codereview.chromium.org/1845283003/diff/140001/include/core/SkCanvas.h
File include/core/SkCanvas.h (right):

https://codereview.chromium.org/1845283003/diff/140001/include/core/SkCanvas....
include/core/SkCanvas.h:127: *  (cpu or gpu), then this will return null.
1. I think recording canvases have a device, so they will return true? Would it
be more correct to say the canvas has to be backed by a surface?

2. How do you feel about returning a copy of the props instead of a bare ptr?

e.g.

bool getProps(SurfaceProps*) const;

https://codereview.chromium.org/1845283003/diff/140001/include/core/SkImageIn...
File include/core/SkImageInfo.h (right):

https://codereview.chromium.org/1845283003/diff/140001/include/core/SkImageIn...
include/core/SkImageInfo.h:323: static inline bool
SkColorAndProfileAreGammaCorrect(SkColorType ct, SkColorProfileType pt) {
doe these need to be public?

https://codereview.chromium.org/1845283003/diff/140001/include/core/SkSurface...
File include/core/SkSurfaceProps.h (right):

https://codereview.chromium.org/1845283003/diff/140001/include/core/SkSurface...
include/core/SkSurfaceProps.h:57: kAllowSRGBInputs_Flag           = 1 << 3,
Lets add some dox for this...

Among other things, will it apply just to images, or to colors/shaders as well?

[Brian Osman, 2016-04-04 21:42:35]

https://codereview.chromium.org/1845283003/diff/140001/include/core/SkCanvas.h
File include/core/SkCanvas.h (right):

https://codereview.chromium.org/1845283003/diff/140001/include/core/SkCanvas....
include/core/SkCanvas.h:127: *  (cpu or gpu), then this will return null.
On 2016/04/04 21:12:29, reed1 wrote:
> 1. I think recording canvases have a device, so they will return true? Would
it
> be more correct to say the canvas has to be backed by a surface?

My understanding (and Brian's claim) was that the recording canvases didn't have
a device. If they do, then the comment on imageInfo() is also wrong - that
function is also implemented to check for the device being null.

> 2. How do you feel about returning a copy of the props instead of a bare ptr?
> 
> e.g.
> 
> bool getProps(SurfaceProps*) const;

I'd be okay with that. It will make a bit more typing in some of the GMs that
I'm fixing up, but not enough to matter. This version of props() is already
strange, because every other class with an SkSurfaceProps accessor returns by
const-ref, so changing the name/signature more to call out the potential for
failure is probably good.

https://codereview.chromium.org/1845283003/diff/140001/include/core/SkImageIn...
File include/core/SkImageInfo.h (right):

https://codereview.chromium.org/1845283003/diff/140001/include/core/SkImageIn...
include/core/SkImageInfo.h:323: static inline bool
SkColorAndProfileAreGammaCorrect(SkColorType ct, SkColorProfileType pt) {
On 2016/04/04 21:12:29, reed1 wrote:
> doe these need to be public?

Probably not. They're intended to be used just inside the edge of our public API
(currently in SkWindow and a few places in DM). Should I move them to someplace
like SkColorPriv.h?

https://codereview.chromium.org/1845283003/diff/140001/include/core/SkSurface...
File include/core/SkSurfaceProps.h (right):

https://codereview.chromium.org/1845283003/diff/140001/include/core/SkSurface...
include/core/SkSurfaceProps.h:57: kAllowSRGBInputs_Flag           = 1 << 3,
On 2016/04/04 21:12:29, reed1 wrote:
> Lets add some dox for this...
> 
> Among other things, will it apply just to images, or to colors/shaders as
well?

I would assume it applies to everything, although that could be open to
discussion. It depends on how we plan to handle those kinds of inputs. If we
require people to explicitly give us sRGB (or other non-linear) colors, then
people can't accidentally break legacy mode with those APIs. With images, it's
very easy, because the codecs need to tag most images sRGB. Of course, for
testing purposes, it's probably best to make the flag as global as possible, so
it basically short-circuits the sRGB interpretation of everything?

[robertphillips, 2016-04-05 12:54:34]

https://codereview.chromium.org/1845283003/diff/160001/include/core/SkCanvas.h
File include/core/SkCanvas.h (right):

https://codereview.chromium.org/1845283003/diff/160001/include/core/SkCanvas....
include/core/SkCanvas.h:125: /**
move these over 1 ' ' ?

https://codereview.chromium.org/1845283003/diff/160001/include/core/SkSurface...
File include/core/SkSurfaceProps.h (right):

https://codereview.chromium.org/1845283003/diff/160001/include/core/SkSurface...
include/core/SkSurfaceProps.h:56: kUseDeviceIndependentFonts_Flag = 1 << 2,
A big old comment here ?

https://codereview.chromium.org/1845283003/diff/160001/include/gpu/GrPaint.h
File include/gpu/GrPaint.h (right):

https://codereview.chromium.org/1845283003/diff/160001/include/gpu/GrPaint.h#...
include/gpu/GrPaint.h:66: /**
Expand on this a bit?

https://codereview.chromium.org/1845283003/diff/160001/src/core/SkCanvas.cpp
File src/core/SkCanvas.cpp (right):

https://codereview.chromium.org/1845283003/diff/160001/src/core/SkCanvas.cpp#...
src/core/SkCanvas.cpp:1337: const SkSurfaceProps* SkCanvas::props() const {
Is this b.c. of the PDFCanvas? If so, what does PDF do with sRGB?

https://codereview.chromium.org/1845283003/diff/160001/src/effects/SkGpuBlurU...
File src/effects/SkGpuBlurUtils.cpp (right):

https://codereview.chromium.org/1845283003/diff/160001/src/effects/SkGpuBlurU...
src/effects/SkGpuBlurUtils.cpp:286: SkAutoTUnref<GrDrawContext> dstDrawContext(
I would probably move this move left and put it on 1 line

https://codereview.chromium.org/1845283003/diff/160001/src/effects/SkGpuBlurU...
src/effects/SkGpuBlurUtils.cpp:321: SkAutoTUnref<GrDrawContext> dstDrawContext(
here too

https://codereview.chromium.org/1845283003/diff/160001/src/effects/SkGpuBlurU...
src/effects/SkGpuBlurUtils.cpp:355: SkAutoTUnref<GrDrawContext> dstDrawContext(
3

https://codereview.chromium.org/1845283003/diff/160001/src/views/SkWindow.cpp
File src/views/SkWindow.cpp (right):

https://codereview.chromium.org/1845283003/diff/160001/src/views/SkWindow.cpp...
src/views/SkWindow.cpp:73: 
// Comment ?

[bsalomon, 2016-04-05 13:24:01]

https://codereview.chromium.org/1845283003/diff/160001/include/core/SkDevice.h
File include/core/SkDevice.h (right):

https://codereview.chromium.org/1845283003/diff/160001/include/core/SkDevice....
include/core/SkDevice.h:396: friend class GrLayerHoister; // for surfaceProps
Wonder why the getter isn't public. Maybe it could be?

https://codereview.chromium.org/1845283003/diff/160001/src/effects/SkAlphaThr...
File src/effects/SkAlphaThresholdFilter.cpp (right):

https://codereview.chromium.org/1845283003/diff/160001/src/effects/SkAlphaThr...
src/effects/SkAlphaThresholdFilter.cpp:315: // SRGBTODO: AllowSRGBInputs?
Nah, this is really drawing a mask.

https://codereview.chromium.org/1845283003/diff/160001/src/effects/SkBlurMask...
File src/effects/SkBlurMaskFilter.cpp (right):

https://codereview.chromium.org/1845283003/diff/160001/src/effects/SkBlurMask...
src/effects/SkBlurMaskFilter.cpp:1248: allowSRGBInputs, clipRect, nullptr,
AFAIK, this is taking an input mask and produced a blurred variation of it. It's
all coverage, no color. Not sure you need the additional param to filterMaskGpu.
I think you  could just pass false to GaussianBlur. (GaussianBlur is also
probably used in image filters where it really is operating on color).

https://codereview.chromium.org/1845283003/diff/160001/src/effects/SkBlurMask...
src/effects/SkBlurMaskFilter.cpp:1256: // SRGBTODO: AllowSRGBInputs?
No, this is taking the blurred mask and the original mask (coverage) and
combining them using a set operation to produce a third mask.

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/GrBlurUtils.cpp
File src/gpu/GrBlurUtils.cpp (right):

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/GrBlurUtils.cp...
src/gpu/GrBlurUtils.cpp:135: // SRGBTODO: AllowSRGBInputs?
This is creating a mask, shouldn't have to worry about srgb.

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/GrBlurUtils.cp...
src/gpu/GrBlurUtils.cpp:341: if (!SkPaintToGrPaint(context, paint, viewMatrix,
drawContext->allowSRGBInputs(),
I think this is right.

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/GrClipMaskMana...
File src/gpu/GrClipMaskManager.cpp (right):

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/GrClipMaskMana...
src/gpu/GrClipMaskManager.cpp:709: // SRGBTODO: AllowSRGBInputs?
This is drawing clips as coverage masks, no need for srgb.

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/GrDrawContext.cpp
File src/gpu/GrDrawContext.cpp (right):

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/GrDrawContext....
src/gpu/GrDrawContext.cpp:389: // SRGBTODO: AllowSRGBInputs?
Shouldn't matter. This is used to draw clip masks and there will never be
anything in the color pipeline.

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/GrDrawContext....
src/gpu/GrDrawContext.cpp:905: // SRGBTODO: AllowSRGBInputs?
Also drawing clip masks here.

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/text/GrStencil...
File src/gpu/text/GrStencilAndCoverTextContext.cpp (right):

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/text/GrStencil...
src/gpu/text/GrStencilAndCoverTextContext.cpp:168: // SRGBTODO: AllowSRGBInputs?
(Is the dc here going to be real/correct)?
It should be correct.

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/text/GrStencil...
src/gpu/text/GrStencilAndCoverTextContext.cpp:224: // SRGBTODO: AllowSRGBInputs?
(Is the dc here going to be real/correct)?
ditto

[Brian Osman, 2016-04-05 15:36:42]

https://codereview.chromium.org/1845283003/diff/160001/include/core/SkCanvas.h
File include/core/SkCanvas.h (right):

https://codereview.chromium.org/1845283003/diff/160001/include/core/SkCanvas....
include/core/SkCanvas.h:125: /**
On 2016/04/05 12:54:34, robertphillips wrote:
> move these over 1 ' ' ?

Acknowledged.

https://codereview.chromium.org/1845283003/diff/160001/include/core/SkDevice.h
File include/core/SkDevice.h (right):

https://codereview.chromium.org/1845283003/diff/160001/include/core/SkDevice....
include/core/SkDevice.h:396: friend class GrLayerHoister; // for surfaceProps
On 2016/04/05 13:24:00, bsalomon wrote:
> Wonder why the getter isn't public. Maybe it could be?

Acknowledged.

https://codereview.chromium.org/1845283003/diff/160001/include/core/SkSurface...
File include/core/SkSurfaceProps.h (right):

https://codereview.chromium.org/1845283003/diff/160001/include/core/SkSurface...
include/core/SkSurfaceProps.h:56: kUseDeviceIndependentFonts_Flag = 1 << 2,
On 2016/04/05 12:54:34, robertphillips wrote:
> A big old comment here ?

Acknowledged.

https://codereview.chromium.org/1845283003/diff/160001/include/gpu/GrPaint.h
File include/gpu/GrPaint.h (right):

https://codereview.chromium.org/1845283003/diff/160001/include/gpu/GrPaint.h#...
include/gpu/GrPaint.h:66: /**
On 2016/04/05 12:54:34, robertphillips wrote:
> Expand on this a bit?

Acknowledged.

https://codereview.chromium.org/1845283003/diff/160001/src/effects/SkAlphaThr...
File src/effects/SkAlphaThresholdFilter.cpp (right):

https://codereview.chromium.org/1845283003/diff/160001/src/effects/SkAlphaThr...
src/effects/SkAlphaThresholdFilter.cpp:315: // SRGBTODO: AllowSRGBInputs?
On 2016/04/05 13:24:00, bsalomon wrote:
> Nah, this is really drawing a mask.

Acknowledged.

https://codereview.chromium.org/1845283003/diff/160001/src/effects/SkBlurMask...
File src/effects/SkBlurMaskFilter.cpp (right):

https://codereview.chromium.org/1845283003/diff/160001/src/effects/SkBlurMask...
src/effects/SkBlurMaskFilter.cpp:1248: allowSRGBInputs, clipRect, nullptr,
On 2016/04/05 13:24:01, bsalomon wrote:
> AFAIK, this is taking an input mask and produced a blurred variation of it.
It's
> all coverage, no color. Not sure you need the additional param to
filterMaskGpu.
> I think you  could just pass false to GaussianBlur. (GaussianBlur is also
> probably used in image filters where it really is operating on color).

Acknowledged.

https://codereview.chromium.org/1845283003/diff/160001/src/effects/SkBlurMask...
src/effects/SkBlurMaskFilter.cpp:1256: // SRGBTODO: AllowSRGBInputs?
On 2016/04/05 13:24:01, bsalomon wrote:
> No, this is taking the blurred mask and the original mask (coverage) and
> combining them using a set operation to produce a third mask.

Acknowledged.

https://codereview.chromium.org/1845283003/diff/160001/src/effects/SkGpuBlurU...
File src/effects/SkGpuBlurUtils.cpp (right):

https://codereview.chromium.org/1845283003/diff/160001/src/effects/SkGpuBlurU...
src/effects/SkGpuBlurUtils.cpp:286: SkAutoTUnref<GrDrawContext> dstDrawContext(
On 2016/04/05 12:54:34, robertphillips wrote:
> I would probably move this move left and put it on 1 line

Acknowledged.

https://codereview.chromium.org/1845283003/diff/160001/src/effects/SkGpuBlurU...
src/effects/SkGpuBlurUtils.cpp:321: SkAutoTUnref<GrDrawContext> dstDrawContext(
On 2016/04/05 12:54:34, robertphillips wrote:
> here too

Acknowledged.

https://codereview.chromium.org/1845283003/diff/160001/src/effects/SkGpuBlurU...
src/effects/SkGpuBlurUtils.cpp:355: SkAutoTUnref<GrDrawContext> dstDrawContext(
On 2016/04/05 12:54:34, robertphillips wrote:
> 3

Acknowledged.

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/GrBlurUtils.cpp
File src/gpu/GrBlurUtils.cpp (right):

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/GrBlurUtils.cp...
src/gpu/GrBlurUtils.cpp:135: // SRGBTODO: AllowSRGBInputs?
On 2016/04/05 13:24:01, bsalomon wrote:
> This is creating a mask, shouldn't have to worry about srgb.

Acknowledged.

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/GrBlurUtils.cp...
src/gpu/GrBlurUtils.cpp:341: if (!SkPaintToGrPaint(context, paint, viewMatrix,
drawContext->allowSRGBInputs(),
On 2016/04/05 13:24:01, bsalomon wrote:
> I think this is right.

Acknowledged.

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/GrClipMaskMana...
File src/gpu/GrClipMaskManager.cpp (right):

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/GrClipMaskMana...
src/gpu/GrClipMaskManager.cpp:709: // SRGBTODO: AllowSRGBInputs?
On 2016/04/05 13:24:01, bsalomon wrote:
> This is drawing clips as coverage masks, no need for srgb.

Acknowledged.

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/GrDrawContext.cpp
File src/gpu/GrDrawContext.cpp (right):

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/GrDrawContext....
src/gpu/GrDrawContext.cpp:389: // SRGBTODO: AllowSRGBInputs?
On 2016/04/05 13:24:01, bsalomon wrote:
> Shouldn't matter. This is used to draw clip masks and there will never be
> anything in the color pipeline.

Acknowledged.

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/GrDrawContext....
src/gpu/GrDrawContext.cpp:905: // SRGBTODO: AllowSRGBInputs?
On 2016/04/05 13:24:01, bsalomon wrote:
> Also drawing clip masks here.

Acknowledged.

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/text/GrStencil...
File src/gpu/text/GrStencilAndCoverTextContext.cpp (right):

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/text/GrStencil...
src/gpu/text/GrStencilAndCoverTextContext.cpp:168: // SRGBTODO: AllowSRGBInputs?
(Is the dc here going to be real/correct)?
On 2016/04/05 13:24:01, bsalomon wrote:
> It should be correct.

Acknowledged.

https://codereview.chromium.org/1845283003/diff/160001/src/gpu/text/GrStencil...
src/gpu/text/GrStencilAndCoverTextContext.cpp:224: // SRGBTODO: AllowSRGBInputs?
(Is the dc here going to be real/correct)?
On 2016/04/05 13:24:01, bsalomon wrote:
> ditto

Acknowledged.

https://codereview.chromium.org/1845283003/diff/160001/src/views/SkWindow.cpp
File src/views/SkWindow.cpp (right):

https://codereview.chromium.org/1845283003/diff/160001/src/views/SkWindow.cpp...
src/views/SkWindow.cpp:73: 
On 2016/04/05 12:54:34, robertphillips wrote:
> // Comment ?

Acknowledged.

[Brian Osman, 2016-04-05 15:47:07]

We were chatting about what exactly the new flag should *do*, so I could
document it correctly. That got me thinking about how some
combinations/use-cases don't really make sense... That got me documenting all
six of the potential combinations, and what the implications are, if the flag
does what it says now (suppress sRGB->Linear for all color pipeline source).
Take a look:

https://docs.google.com/a/google.com/document/d/1tO-BJpLNA8pQaat4YlY_cCOSm1s0...

[Brian Osman, 2016-04-05 15:51:59]

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

[commit-bot: I haz the power, 2016-04-05 15:52:03]

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

[commit-bot: I haz the power, 2016-04-05 16:03:00]

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

[commit-bot: I haz the power, 2016-04-05 16:03:01]

Dry run: This issue passed the CQ dry run.

[Brian Osman, 2016-04-05 20:09:36]

Review feedback should be addressed. Look good?

[bsalomon, 2016-04-06 13:19:28]

lgtm, some more comments on some of the SRGBTODOs (though not looking for any
changes in this CL).

https://codereview.chromium.org/1845283003/diff/220001/src/effects/SkImageSou...
File src/effects/SkImageSource.cpp (right):

https://codereview.chromium.org/1845283003/diff/220001/src/effects/SkImageSou...
src/effects/SkImageSource.cpp:77: // SRGBTODO: Propagate SkColorType?
If Rob doesn't know the answer to this I'd check with senorblanco@

https://codereview.chromium.org/1845283003/diff/220001/src/effects/SkLighting...
File src/effects/SkLightingImageFilter.cpp (right):

https://codereview.chromium.org/1845283003/diff/220001/src/effects/SkLighting...
src/effects/SkLightingImageFilter.cpp:390: // SRGBTODO: AllowSRGBInputs?
Also senorblanco@

https://codereview.chromium.org/1845283003/diff/220001/src/effects/SkMorpholo...
File src/effects/SkMorphologyImageFilter.cpp (right):

https://codereview.chromium.org/1845283003/diff/220001/src/effects/SkMorpholo...
src/effects/SkMorphologyImageFilter.cpp:373: // SRGBTODO: AllowSRGBInputs?
probably should depend on the drawContext at the root of the filter dag. Not
sure how that should make it here.

https://codereview.chromium.org/1845283003/diff/220001/src/effects/SkMorpholo...
src/effects/SkMorphologyImageFilter.cpp:393: // SRGBTODO: AllowSRGBInputs?
ditto

https://codereview.chromium.org/1845283003/diff/220001/src/effects/SkXfermode...
File src/effects/SkXfermodeImageFilter.cpp (right):

https://codereview.chromium.org/1845283003/diff/220001/src/effects/SkXfermode...
src/effects/SkXfermodeImageFilter.cpp:176: // SRGBTODO: AllowSRGBInputs?
This in the deprecated code path, probably doesn't matter.  But when new code
path is written for this filter it should be based on the device/drawContext at
the root.

[Brian Osman, 2016-04-06 13:45:27]

The CQ bit was checked by brianosman@google.com

[commit-bot: I haz the power, 2016-04-06 13:45:30]

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

[commit-bot: I haz the power, 2016-04-06 14:38:25]

Description was changed from

==========
SkSurfaceProps now has a gamma-correct ("AllowSRGBInputs") flag. That's
propagated in a few places so that the backend can do the right thing for L32 vs
S32 mode.

Also added SkSurfaceProps to SkSpecialImage, so that Image -> Surface conversion
can preserve the desired behavior during filtering.

Many small changes, including a bunch of comments about places where we may be
losing information right now. My approach was to ensure that if anything fails,
it will always fall back to "legacy" mode - gamma-correctness is opt-in, so I'll
just have to feed things through as missing cases are exposed.
BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

to

==========
SkSurfaceProps now has a gamma-correct ("AllowSRGBInputs") flag. That's
propagated in a few places so that the backend can do the right thing for L32 vs
S32 mode.

Also added SkSurfaceProps to SkSpecialImage, so that Image -> Surface conversion
can preserve the desired behavior during filtering.

Many small changes, including a bunch of comments about places where we may be
losing information right now. My approach was to ensure that if anything fails,
it will always fall back to "legacy" mode - gamma-correctness is opt-in, so I'll
just have to feed things through as missing cases are exposed.
BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...

Committed:
https://skia.googlesource.com/skia/+/898235c4864df66aa7f6d32bc2a8b8551040ce1e
==========

[commit-bot: I haz the power, 2016-04-06 14:38:27]

Committed patchset #12 (id:220001) as
https://skia.googlesource.com/skia/+/898235c4864df66aa7f6d32bc2a8b8551040ce1e