sRGB support in Ganesh. Several pieces:

sRGB support in Ganesh. Several pieces:

sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
us to disable sRGB -> Linear conversion when reading textures. This gives
us an easy way to support "legacy" L32 mode. We disable decoding based on
the pixel config of the render target. Textures can override that behavior
(specifically for format-conversion draws where we want that behavior).

Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
internally, and the external format is BGR order, so TexImage calls will
swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
platforms.

Devices without sRGB support behave like they always have: conversion from
color type and profile type ignores sRGB and always returns linear pixel
configs.

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

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

[Brian Osman, 2016-03-11 15:54:43]

Description was changed from

==========
sRGB support in Ganesh. Several pieces:

sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
us to disable sRGB -> Linear conversion when reading textures. This gives
us an easy way to support "legacy" L32 mode. We disable decoding based on
the pixel config of the render target. Textures can override that behavior
(specifically for format-conversion draws where we want that behavior).

Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
internally, and the external format is BGR order, so TexImage calls will
swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
platforms.

Devices without sRGB support use a hack in the config table to treat sRGB
formats exactly like equivalent non-sRGB formats. Avoids regressions on
those devices when sRGB data leaks into Ganesh. (Usually from the PNG
decoder). This lie means that we need to explicitly disable the
SRGBReadWritePixels test on those devices, because they will claim that
sRGB is renderable and texturable, but not implement any of the sRGB
behavior.

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

to

==========
sRGB support in Ganesh. Several pieces:

sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
us to disable sRGB -> Linear conversion when reading textures. This gives
us an easy way to support "legacy" L32 mode. We disable decoding based on
the pixel config of the render target. Textures can override that behavior
(specifically for format-conversion draws where we want that behavior).

Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
internally, and the external format is BGR order, so TexImage calls will
swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
platforms.

Devices without sRGB support use a hack in the config table to treat sRGB
formats exactly like equivalent non-sRGB formats. Avoids regressions on
those devices when sRGB data leaks into Ganesh. (Usually from the PNG
decoder). This lie means that we need to explicitly disable the
SRGBReadWritePixels test on those devices, because they will claim that
sRGB is renderable and texturable, but not implement any of the sRGB
behavior.

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

[Brian Osman, 2016-03-11 17:15:24]

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

[Brian Osman, 2016-03-11 17:15:25]

https://codereview.chromium.org/1789663002/diff/20001/src/gpu/gl/GrGLGpu.cpp
File src/gpu/gl/GrGLGpu.cpp (right):

https://codereview.chromium.org/1789663002/diff/20001/src/gpu/gl/GrGLGpu.cpp#...
src/gpu/gl/GrGLGpu.cpp:2596: ElevateDrawPreference(drawPreference,
kRequireDraw_DrawPreference);
This block of code may make no sense, given how sBGRA is implemented.

[bsalomon, 2016-03-11 23:16:20]

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

https://codereview.chromium.org/1789663002/diff/20001/src/gpu/SkGr.cpp#newcod...
src/gpu/SkGr.cpp:373: ? kSRGBA_8888_GrPixelConfig
Should we fail if pt is srgb but ct is not rgba_8888 or bgra_8888?

https://codereview.chromium.org/1789663002/diff/20001/src/gpu/gl/GrGLCaps.cpp
File src/gpu/gl/GrGLCaps.cpp (right):

https://codereview.chromium.org/1789663002/diff/20001/src/gpu/gl/GrGLCaps.cpp...
src/gpu/gl/GrGLCaps.cpp:1783: // in ES 2.0, because there is no <internalFormat>
we can use. So just make that format
Not true on ES 3.0+?

https://codereview.chromium.org/1789663002/diff/20001/src/gpu/gl/GrGLCaps.cpp...
src/gpu/gl/GrGLCaps.cpp:1805: // to function as it always has, where everything
is treated as linear. This isn't the
Can we pass the caps to the ct/at/pt -> grpc conversion and avoid this hack?

[Brian Osman, 2016-03-17 14:31:40]

Description was changed from

==========
sRGB support in Ganesh. Several pieces:

sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
us to disable sRGB -> Linear conversion when reading textures. This gives
us an easy way to support "legacy" L32 mode. We disable decoding based on
the pixel config of the render target. Textures can override that behavior
(specifically for format-conversion draws where we want that behavior).

Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
internally, and the external format is BGR order, so TexImage calls will
swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
platforms.

Devices without sRGB support use a hack in the config table to treat sRGB
formats exactly like equivalent non-sRGB formats. Avoids regressions on
those devices when sRGB data leaks into Ganesh. (Usually from the PNG
decoder). This lie means that we need to explicitly disable the
SRGBReadWritePixels test on those devices, because they will claim that
sRGB is renderable and texturable, but not implement any of the sRGB
behavior.

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

to

==========
sRGB support in Ganesh. Several pieces:

sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
us to disable sRGB -> Linear conversion when reading textures. This gives
us an easy way to support "legacy" L32 mode. We disable decoding based on
the pixel config of the render target. Textures can override that behavior
(specifically for format-conversion draws where we want that behavior).

Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
internally, and the external format is BGR order, so TexImage calls will
swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
platforms.

Devices without sRGB support behave like they always have: conversion from
color type and profile type ignores sRGB and always returns linear pixel
configs.

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

[Brian Osman, 2016-03-17 14:32:06]

Fixed various problems.

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

https://codereview.chromium.org/1789663002/diff/20001/src/gpu/SkGr.cpp#newcod...
src/gpu/SkGr.cpp:373: ? kSRGBA_8888_GrPixelConfig
On 2016/03/11 23:16:19, bsalomon wrote:
> Should we fail if pt is srgb but ct is not rgba_8888 or bgra_8888?

Done.

https://codereview.chromium.org/1789663002/diff/20001/src/gpu/gl/GrGLCaps.cpp
File src/gpu/gl/GrGLCaps.cpp (right):

https://codereview.chromium.org/1789663002/diff/20001/src/gpu/gl/GrGLCaps.cpp...
src/gpu/gl/GrGLCaps.cpp:1783: // in ES 2.0, because there is no <internalFormat>
we can use. So just make that format
On 2016/03/11 23:16:20, bsalomon wrote:
> Not true on ES 3.0+?

My reading of this is that it's allowed? ES2 forces the two formats to match,
but ES3 will let us do conversion at Tex[Sub]Image time?

https://codereview.chromium.org/1789663002/diff/20001/src/gpu/gl/GrGLCaps.cpp...
src/gpu/gl/GrGLCaps.cpp:1805: // to function as it always has, where everything
is treated as linear. This isn't the
On 2016/03/11 23:16:20, bsalomon wrote:
> Can we pass the caps to the ct/at/pt -> grpc conversion and avoid this hack?

Done.

[bsalomon, 2016-03-17 14:54:48]

https://codereview.chromium.org/1789663002/diff/100001/include/gpu/GrTypes.h
File include/gpu/GrTypes.h (right):

https://codereview.chromium.org/1789663002/diff/100001/include/gpu/GrTypes.h#...
include/gpu/GrTypes.h:406: kUnknown_GrSRGBPolicy,
What does unknown mean? Can we get away with just allow and suppress and at bind
time suppress if either params or the value implied by the config says suppress?

[Brian Osman, 2016-03-17 15:01:22]

https://codereview.chromium.org/1789663002/diff/100001/include/gpu/GrTypes.h
File include/gpu/GrTypes.h (right):

https://codereview.chromium.org/1789663002/diff/100001/include/gpu/GrTypes.h#...
include/gpu/GrTypes.h:406: kUnknown_GrSRGBPolicy,
On 2016/03/17 14:54:47, bsalomon wrote:
> What does unknown mean? Can we get away with just allow and suppress and at
bind
> time suppress if either params or the value implied by the config says
suppress?

Currently, the only use of the params override is to force "Allow" (not
"Suppress"). We could shrink the enum and put an extra boolean on texture params
that indicates if the value should be used. That limits the scope of the 'third
state', but didn't feel much better than this solution. (I agree that this is
klunky - I tried to come up with a better solution when I added this,
particularly because it makes the code in bindTexture somewhat trickier to
read).

[Brian Osman, 2016-03-17 16:05:10]

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

[commit-bot: I haz the power, 2016-03-17 16:05:13]

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

[commit-bot: I haz the power, 2016-03-17 16:06:43]

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

[commit-bot: I haz the power, 2016-03-17 16:06:44]

Dry run: Try jobs failed on following builders:
  Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-Shared-Trybot on client.skia
(JOB_FAILED,
http://build.chromium.org/p/client.skia/builders/Test-Ubuntu-GCC-GCE-CPU-AVX2...)

[Brian Osman, 2016-03-17 16:18:41]

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

[commit-bot: I haz the power, 2016-03-17 16:18:53]

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

[commit-bot: I haz the power, 2016-03-17 16:21:43]

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

[commit-bot: I haz the power, 2016-03-17 16:21:44]

Dry run: Try jobs failed on following builders:
  Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Debug-Trybot on client.skia (JOB_FAILED,
http://build.chromium.org/p/client.skia/builders/Test-Ubuntu-GCC-GCE-CPU-AVX2...)
  Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-Shared-Trybot on client.skia
(JOB_FAILED,
http://build.chromium.org/p/client.skia/builders/Test-Ubuntu-GCC-GCE-CPU-AVX2...)
  Build-Ubuntu-Clang-x86_64-Debug-Trybot on client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-Clang-x...)

[Brian Osman, 2016-03-17 17:00:00]

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

[commit-bot: I haz the power, 2016-03-17 17:00:12]

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

[commit-bot: I haz the power, 2016-03-17 17:03:52]

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

[commit-bot: I haz the power, 2016-03-17 17:03:53]

Dry run: Try jobs failed on following builders:
  Build-Ubuntu-Clang-x86_64-Debug-Trybot on client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-Clang-x...)

[Brian Osman, 2016-03-17 18:02:48]

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

[commit-bot: I haz the power, 2016-03-17 18:02:58]

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

[Brian Osman, 2016-03-17 18:07:03]

https://codereview.chromium.org/1789663002/diff/180001/gyp/common_conditions....
File gyp/common_conditions.gypi (right):

https://codereview.chromium.org/1789663002/diff/180001/gyp/common_conditions....
gyp/common_conditions.gypi:235: '-Wno-tautological-compare',
Is this okay? Without this, clang is warning on code like:
void foo(GrPixelConfig x) { SkASSERT(x < kGrPixelConfigCnt); }

I've added a new pixel config (which automatically adjusts kGrPixelConfigCnt),
but it's not clear to me why clang is now unhappy. People have suggested online
that you can suppress this at the site by casting the enum-typed variable to int
before the comparison. Would that be better than disabling this warning
globally?

[commit-bot: I haz the power, 2016-03-17 18:23:49]

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

[commit-bot: I haz the power, 2016-03-17 18:23:50]

Dry run: This issue passed the CQ dry run.

[Brian Osman, 2016-03-17 18:32:04]

The CQ bit was checked by brianosman@google.com

[commit-bot: I haz the power, 2016-03-17 18:32:16]

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

[commit-bot: I haz the power, 2016-03-17 18:32:18]

Note for Reviewers:
The CQ is waiting for an approval.
If you believe that the CL is not ready yet, or if you would like to L-G-T-M
with comments then please uncheck the CQ checkbox.

Waiting for LGTM from valid reviewer(s) till 2016-03-18 00:32 UTC

[commit-bot: I haz the power, 2016-03-17 18:34:07]

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

[commit-bot: I haz the power, 2016-03-17 18:34:09]

Try jobs failed on following builders:
  skia_presubmit-Trybot on client.skia.fyi (JOB_FAILED,
http://build.chromium.org/p/client.skia.fyi/builders/skia_presubmit-Trybot/bu...)

[bsalomon, 2016-03-17 18:47:45]

On 2016/03/17 18:07:03, Brian Osman wrote:
>
https://codereview.chromium.org/1789663002/diff/180001/gyp/common_conditions....
> File gyp/common_conditions.gypi (right):
> 
>
https://codereview.chromium.org/1789663002/diff/180001/gyp/common_conditions....
> gyp/common_conditions.gypi:235: '-Wno-tautological-compare',
> Is this okay? Without this, clang is warning on code like:
> void foo(GrPixelConfig x) { SkASSERT(x < kGrPixelConfigCnt); }
> 
> I've added a new pixel config (which automatically adjusts kGrPixelConfigCnt),
> but it's not clear to me why clang is now unhappy. People have suggested
online
> that you can suppress this at the site by casting the enum-typed variable to
int
> before the comparison. Would that be better than disabling this warning
> globally?

I'm ok with just deleting those asserts. I don't think they're very useful.

[bsalomon, 2016-03-17 18:51:19]

lgtm

https://codereview.chromium.org/1789663002/diff/200001/src/gpu/gl/GrGLGpu.h
File src/gpu/gl/GrGLGpu.h (right):

https://codereview.chromium.org/1789663002/diff/200001/src/gpu/gl/GrGLGpu.h#n...
src/gpu/gl/GrGLGpu.h:62: void bindTexture(int unitIdx, const GrTextureParams&
params, bool allowSRGB,
Should we make the param name clearly associated with the dst? e.g.
dstConfigAllowsSRGB?

It's ok to use an ugly long name when we're doing an ugly complicated thing.

[Brian Osman, 2016-03-17 19:11:48]

The CQ bit was checked by brianosman@google.com

[Brian Osman, 2016-03-17 19:11:49]

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/1789663002/#ps220001
(title: "Review feedback.")

[commit-bot: I haz the power, 2016-03-17 19:11:59]

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

[commit-bot: I haz the power, 2016-03-17 19:26:39]

Description was changed from

==========
sRGB support in Ganesh. Several pieces:

sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
us to disable sRGB -> Linear conversion when reading textures. This gives
us an easy way to support "legacy" L32 mode. We disable decoding based on
the pixel config of the render target. Textures can override that behavior
(specifically for format-conversion draws where we want that behavior).

Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
internally, and the external format is BGR order, so TexImage calls will
swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
platforms.

Devices without sRGB support behave like they always have: conversion from
color type and profile type ignores sRGB and always returns linear pixel
configs.

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

to

==========
sRGB support in Ganesh. Several pieces:

sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
us to disable sRGB -> Linear conversion when reading textures. This gives
us an easy way to support "legacy" L32 mode. We disable decoding based on
the pixel config of the render target. Textures can override that behavior
(specifically for format-conversion draws where we want that behavior).

Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
internally, and the external format is BGR order, so TexImage calls will
swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
platforms.

Devices without sRGB support behave like they always have: conversion from
color type and profile type ignores sRGB and always returns linear pixel
configs.

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/+/9e3f1bf4e5cd8fc59554f986f36d6b034e99f9eb
==========

[commit-bot: I haz the power, 2016-03-17 19:26:40]

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

[Brian Osman, 2016-03-17 20:01:07]

A revert of this CL (patchset #12 id:220001) has been created in
https://codereview.chromium.org/1814533003/ by brianosman@google.com.

The reason for reverting is: We're getting sRGB non-8888 configs?.

[Brian Osman, 2016-03-18 14:36:57]

Description was changed from

==========
sRGB support in Ganesh. Several pieces:

sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
us to disable sRGB -> Linear conversion when reading textures. This gives
us an easy way to support "legacy" L32 mode. We disable decoding based on
the pixel config of the render target. Textures can override that behavior
(specifically for format-conversion draws where we want that behavior).

Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
internally, and the external format is BGR order, so TexImage calls will
swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
platforms.

Devices without sRGB support behave like they always have: conversion from
color type and profile type ignores sRGB and always returns linear pixel
configs.

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/+/9e3f1bf4e5cd8fc59554f986f36d6b034e99f9eb
==========

to

==========
sRGB support in Ganesh. Several pieces:

sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
us to disable sRGB -> Linear conversion when reading textures. This gives
us an easy way to support "legacy" L32 mode. We disable decoding based on
the pixel config of the render target. Textures can override that behavior
(specifically for format-conversion draws where we want that behavior).

Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
internally, and the external format is BGR order, so TexImage calls will
swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
platforms.

Devices without sRGB support behave like they always have: conversion from
color type and profile type ignores sRGB and always returns linear pixel
configs.

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

[Brian Osman, 2016-03-18 14:37:18]

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

[commit-bot: I haz the power, 2016-03-18 14:37:23]

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

[Brian Osman, 2016-03-18 14:49:02]

The CQ bit was unchecked by brianosman@google.com

[Brian Osman, 2016-03-18 14:49:15]

The CQ bit was checked by brianosman@google.com

[Brian Osman, 2016-03-18 14:49:15]

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/1789663002/#ps260001
(title: "Rebase")

[commit-bot: I haz the power, 2016-03-18 14:49:24]

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

[Brian Osman, 2016-03-18 14:59:16]

The CQ bit was unchecked by brianosman@google.com

[Brian Osman, 2016-03-18 19:55:01]

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

[commit-bot: I haz the power, 2016-03-18 19:55:12]

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

[commit-bot: I haz the power, 2016-03-18 20:14:30]

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

[commit-bot: I haz the power, 2016-03-18 20:14:31]

Dry run: This issue passed the CQ dry run.

[Brian Osman, 2016-03-18 21:36:58]

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

[commit-bot: I haz the power, 2016-03-18 21:37:02]

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

[commit-bot: I haz the power, 2016-03-18 21:56:45]

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

[commit-bot: I haz the power, 2016-03-18 21:56:46]

Dry run: This issue passed the CQ dry run.

[Brian Osman, 2016-03-18 23:46:28]

Various improvements since the last attempt: Non-8888 sRGB textures are expanded
to 8888, some further cleanup.

I've tried to test this as thoroughly as I can, although I don't have a non-BGRA
desktop machine. In my testing, I have about 10 ANGLE gms that change (in legacy
mode). However, all but two of those gms were previously incorrect on ANGLE
anyway - it seems like we have a lot of rendering errors on ANGLE?

I'd really like to get this landed...

[Brian Osman, 2016-03-21 13:44:20]

The CQ bit was checked by brianosman@google.com

[Brian Osman, 2016-03-21 13:44:21]

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/1789663002/#ps340001
(title: "Squelch assert when blurring sRGB")

[commit-bot: I haz the power, 2016-03-21 13:44:28]

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

[commit-bot: I haz the power, 2016-03-21 13:55:47]

Description was changed from

==========
sRGB support in Ganesh. Several pieces:

sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
us to disable sRGB -> Linear conversion when reading textures. This gives
us an easy way to support "legacy" L32 mode. We disable decoding based on
the pixel config of the render target. Textures can override that behavior
(specifically for format-conversion draws where we want that behavior).

Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
internally, and the external format is BGR order, so TexImage calls will
swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
platforms.

Devices without sRGB support behave like they always have: conversion from
color type and profile type ignores sRGB and always returns linear pixel
configs.

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

to

==========
sRGB support in Ganesh. Several pieces:

sRGB support now also requires GL_EXT_texture_sRGB_decode, which allows
us to disable sRGB -> Linear conversion when reading textures. This gives
us an easy way to support "legacy" L32 mode. We disable decoding based on
the pixel config of the render target. Textures can override that behavior
(specifically for format-conversion draws where we want that behavior).

Added sBGRA pixel config, which is not-really-a-format. It's just sRGBA
internally, and the external format is BGR order, so TexImage calls will
swizzle correctly. This lets us interact with sRGB raster surfaces on BGR
platforms.

Devices without sRGB support behave like they always have: conversion from
color type and profile type ignores sRGB and always returns linear pixel
configs.

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/+/a6359365887048ef055196de75591311d7a015f0
==========

[commit-bot: I haz the power, 2016-03-21 13:55:49]

Committed patchset #18 (id:340001) as
https://skia.googlesource.com/skia/+/a6359365887048ef055196de75591311d7a015f0