Added --deepColor option to SampleApp, triggers creation of a ten-bit/channel buffer on Windows.

Added --deepColor option to SampleApp, triggers creation of a ten-bit/channel
buffer. (Only on Windows at the moment). Uses new effect to do the final
gamma adjustment

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

Committed: https://skia.googlesource.com/skia/+/2d1ee7936e3536e45c963db004e3b512bb415fd8

[Brian Osman, 2016-04-25 20:13:12]

Description was changed from

==========
Added --tenBit option to SampleApp, triggers creation of a ten-bit/channel
buffer.

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

to

==========
Added --tenBit option to SampleApp, triggers creation of a ten-bit/channel
buffer.

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

[Brian Osman, 2016-04-27 19:53:03]

Description was changed from

==========
Added --tenBit option to SampleApp, triggers creation of a ten-bit/channel
buffer.

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

to

==========
Added --tenBit option to SampleApp, triggers creation of a ten-bit/channel
buffer.
(Only on Windows at the moment). Uses new effect to do the final gamma
adjustment,
and an ugly code path that parallels writePixels. Like Brian said, it would be
really nice to decouple the machinery of wrapping things in a texture from the
actual color correction pass - if we had the SkSurface, that would be much
easier.

Additionally: At one point I was implementing this as a color filter, but Mike
convinced me that it was the wrong point in the pipeline ... that may be
somewhat
true, but I'm no longer sure that this should be so constrained. If we're
dealing
with images and attached color spaces (ie Matt's code), it seems that we may
want to do the conversion at different points in the pipeline, for performance/
memory/correctness reasons. Or is that just an over-arching special case that's
orthogonal to the Skia pipeline, and we need to handle injecting color-space
conversion immediately after texture sampling for any/all sources? Food for
thought.

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

[Brian Osman, 2016-04-27 19:54:18]

Description was changed from

==========
Added --tenBit option to SampleApp, triggers creation of a ten-bit/channel
buffer.
(Only on Windows at the moment). Uses new effect to do the final gamma
adjustment,
and an ugly code path that parallels writePixels. Like Brian said, it would be
really nice to decouple the machinery of wrapping things in a texture from the
actual color correction pass - if we had the SkSurface, that would be much
easier.

Additionally: At one point I was implementing this as a color filter, but Mike
convinced me that it was the wrong point in the pipeline ... that may be
somewhat
true, but I'm no longer sure that this should be so constrained. If we're
dealing
with images and attached color spaces (ie Matt's code), it seems that we may
want to do the conversion at different points in the pipeline, for performance/
memory/correctness reasons. Or is that just an over-arching special case that's
orthogonal to the Skia pipeline, and we need to handle injecting color-space
conversion immediately after texture sampling for any/all sources? Food for
thought.

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

to

==========
Added --tenBit option to SampleApp, triggers creation of a ten-bit/channel
buffer. (Only on Windows at the moment). Uses new effect to do the final
gamma adjustment, and an ugly code path that parallels writePixels. Like
Brian said, it would be really nice to decouple the machinery of wrapping
things in a texture from the actual color correction pass - if we had the
SkSurface, that would be much easier.

Additionally: At one point I was implementing this as a color filter, but
Mike convinced me that it was the wrong point in the pipeline ... that may
be somewhat true, but I'm no longer sure that this should be so constrained.
If we're dealing with images and attached color spaces (ie Matt's code), it
seems that we may want to do the conversion at different points in the
pipeline, for performance/memory/correctness reasons. Or is that just an
over-arching special case that's orthogonal to the Skia pipeline, and we
need to handle injecting color-space conversion immediately after texture
sampling for any/all sources? Food for thought.

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

[Brian Osman, 2016-04-27 19:55:01]

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

[Brian Osman, 2016-04-27 19:55:02]

https://codereview.chromium.org/1919993002/diff/120001/samplecode/SampleApp.cpp
File samplecode/SampleApp.cpp (right):

https://codereview.chromium.org/1919993002/diff/120001/samplecode/SampleApp.c...
samplecode/SampleApp.cpp:226: bool result = win->attach(fBackend,
msaaSampleCount, tenBitColor, &attachmentInfo);
Seems like I should add fColorBits to AttachmentInfo, so we can determine if we
actually got a 10 bpc window back?

https://codereview.chromium.org/1919993002/diff/120001/samplecode/SampleApp.c...
samplecode/SampleApp.cpp:326: canvas->readPixels(&bm, 0, 0);
This is really ugly, but I couldn't find a way to get from SkCanvas to any of
the "modern" types (SkSurface or SkImage)? The canvas is attached to the surface
we created above, but we've lost that reference, and can't get it back. Surface
has makeImageSnapshot, but that's it. So yeah - this code is stuck going through
SkBitmap and readPixels...

Another option is to alter the signatures of functions on SkView, so we pass the
surface in addition to (or instead of) the canvas, but that's somewhat
invasive...

[bsalomon, 2016-04-27 20:28:24]

https://codereview.chromium.org/1919993002/diff/120001/samplecode/SampleApp.cpp
File samplecode/SampleApp.cpp (right):

https://codereview.chromium.org/1919993002/diff/120001/samplecode/SampleApp.c...
samplecode/SampleApp.cpp:326: canvas->readPixels(&bm, 0, 0);
On 2016/04/27 19:55:01, Brian Osman wrote:
> This is really ugly, but I couldn't find a way to get from SkCanvas to any of
> the "modern" types (SkSurface or SkImage)? The canvas is attached to the
surface
> we created above, but we've lost that reference, and can't get it back.
Surface
> has makeImageSnapshot, but that's it. So yeah - this code is stuck going
through
> SkBitmap and readPixels...
> 
> Another option is to alter the signatures of functions on SkView, so we pass
the
> surface in addition to (or instead of) the canvas, but that's somewhat
> invasive...

My gut take is that this adds too much technical debt
(writePixelsWithColorSpace) than is justified by the end result of making
SampleApp work with ten bit. I think we should push harder on making it possible
to get a SkImage here. Even conceding that we can't directly get a SkImage from
the canvas, taking bm and here and wrapping it via
SkImage::MakeTextureFromPixmap and then having something like a

GrTexture* GrContext::applyColorSpace(GrTexture*, colorSpace)

function would be a big improvement.

[Brian Osman, 2016-04-29 13:57:26]

On 2016/04/27 20:28:24, bsalomon wrote:
>
https://codereview.chromium.org/1919993002/diff/120001/samplecode/SampleApp.cpp
> File samplecode/SampleApp.cpp (right):
> 
>
https://codereview.chromium.org/1919993002/diff/120001/samplecode/SampleApp.c...
> samplecode/SampleApp.cpp:326: canvas->readPixels(&bm, 0, 0);
> On 2016/04/27 19:55:01, Brian Osman wrote:
> > This is really ugly, but I couldn't find a way to get from SkCanvas to any
of
> > the "modern" types (SkSurface or SkImage)? The canvas is attached to the
> surface
> > we created above, but we've lost that reference, and can't get it back.
> Surface
> > has makeImageSnapshot, but that's it. So yeah - this code is stuck going
> through
> > SkBitmap and readPixels...
> > 
> > Another option is to alter the signatures of functions on SkView, so we pass
> the
> > surface in addition to (or instead of) the canvas, but that's somewhat
> > invasive...
> 
> My gut take is that this adds too much technical debt
> (writePixelsWithColorSpace) than is justified by the end result of making
> SampleApp work with ten bit. I think we should push harder on making it
possible
> to get a SkImage here. Even conceding that we can't directly get a SkImage
from
> the canvas, taking bm and here and wrapping it via
> SkImage::MakeTextureFromPixmap and then having something like a
> 
> GrTexture* GrContext::applyColorSpace(GrTexture*, colorSpace)
> 
> function would be a big improvement.

Are you imagining that this would convert the passed-in texture from its current
color space to the requested color-space, and then return a new texture? So the
10-bit flow would be:

- Render to linear F16 in some gamut
- Apply color space to get a new F16 texture in device gamut and gamma
- Render the resulting texture to the output device (via fCurRenderTarget in
  this case)

That would at least isolate the color-space stuff, although I was hoping to do
the last two parts in one step. Oh well.

[bsalomon, 2016-04-29 14:37:30]

On 2016/04/29 13:57:26, Brian Osman wrote:
> On 2016/04/27 20:28:24, bsalomon wrote:
> >
>
https://codereview.chromium.org/1919993002/diff/120001/samplecode/SampleApp.cpp
> > File samplecode/SampleApp.cpp (right):
> > 
> >
>
https://codereview.chromium.org/1919993002/diff/120001/samplecode/SampleApp.c...
> > samplecode/SampleApp.cpp:326: canvas->readPixels(&bm, 0, 0);
> > On 2016/04/27 19:55:01, Brian Osman wrote:
> > > This is really ugly, but I couldn't find a way to get from SkCanvas to any
> of
> > > the "modern" types (SkSurface or SkImage)? The canvas is attached to the
> > surface
> > > we created above, but we've lost that reference, and can't get it back.
> > Surface
> > > has makeImageSnapshot, but that's it. So yeah - this code is stuck going
> > through
> > > SkBitmap and readPixels...
> > > 
> > > Another option is to alter the signatures of functions on SkView, so we
pass
> > the
> > > surface in addition to (or instead of) the canvas, but that's somewhat
> > > invasive...
> > 
> > My gut take is that this adds too much technical debt
> > (writePixelsWithColorSpace) than is justified by the end result of making
> > SampleApp work with ten bit. I think we should push harder on making it
> possible
> > to get a SkImage here. Even conceding that we can't directly get a SkImage
> from
> > the canvas, taking bm and here and wrapping it via
> > SkImage::MakeTextureFromPixmap and then having something like a
> > 
> > GrTexture* GrContext::applyColorSpace(GrTexture*, colorSpace)
> > 
> > function would be a big improvement.
> 
> Are you imagining that this would convert the passed-in texture from its
current
> color space to the requested color-space, and then return a new texture? So
the
> 10-bit flow would be:
> 
> - Render to linear F16 in some gamut
> - Apply color space to get a new F16 texture in device gamut and gamma
> - Render the resulting texture to the output device (via fCurRenderTarget in
>   this case)
> 
> That would at least isolate the color-space stuff, although I was hoping to do
> the last two parts in one step. Oh well.

I wasn't thinking about that fact that you already had the dst allocated. How
about

GrContext::applyColorSpace(GrRenderTarget* dst, GrTexture* src, const
SkColorSpace&) ?

[Brian Osman, 2016-04-29 16:47:38]

Description was changed from

==========
Added --tenBit option to SampleApp, triggers creation of a ten-bit/channel
buffer. (Only on Windows at the moment). Uses new effect to do the final
gamma adjustment, and an ugly code path that parallels writePixels. Like
Brian said, it would be really nice to decouple the machinery of wrapping
things in a texture from the actual color correction pass - if we had the
SkSurface, that would be much easier.

Additionally: At one point I was implementing this as a color filter, but
Mike convinced me that it was the wrong point in the pipeline ... that may
be somewhat true, but I'm no longer sure that this should be so constrained.
If we're dealing with images and attached color spaces (ie Matt's code), it
seems that we may want to do the conversion at different points in the
pipeline, for performance/memory/correctness reasons. Or is that just an
over-arching special case that's orthogonal to the Skia pipeline, and we
need to handle injecting color-space conversion immediately after texture
sampling for any/all sources? Food for thought.

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

to

==========
Added --tenBit option to SampleApp, triggers creation of a ten-bit/channel
buffer. (Only on Windows at the moment). Uses new effect to do the final
gamma adjustment

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

[Brian Osman, 2016-04-29 16:51:19]

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

[commit-bot: I haz the power, 2016-04-29 16:51:47]

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

[Brian Osman, 2016-04-29 16:51:51]

Stripped down to a much simpler and cleaner implementation...

[commit-bot: I haz the power, 2016-04-29 16:56:15]

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

[commit-bot: I haz the power, 2016-04-29 16:56:15]

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-04-29 18:25:55]

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

[commit-bot: I haz the power, 2016-04-29 18:26:00]

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

[bsalomon, 2016-04-29 18:27:20]

I like this much better!

https://codereview.chromium.org/1919993002/diff/200001/include/gpu/GrContext.h
File include/gpu/GrContext.h (right):

https://codereview.chromium.org/1919993002/diff/200001/include/gpu/GrContext....
include/gpu/GrContext.h:302: */
Question about this API:

Can dst and src be different sizes? If so what happens? Should it take a
srcRect, dstPoint a la copySurface?

Perhaps we should have some unit tests for this (CopySurfaceTest.cpp might be a
decent starting point).

https://codereview.chromium.org/1919993002/diff/200001/src/gpu/GrContext.cpp
File src/gpu/GrContext.cpp (right):

https://codereview.chromium.org/1919993002/diff/200001/src/gpu/GrContext.cpp#...
src/gpu/GrContext.cpp:548: if (SkScalarNearlyEqual(gamma, 1.0f)) {
Maybe just call copySurface here? Should we also detect the case that the src is
linear and the dst is srgb and the specified gamma was 2.2 and let the hw do it?

https://codereview.chromium.org/1919993002/diff/200001/src/gpu/effects/GrGamm...
File src/gpu/effects/GrGammaEffect.h (right):

https://codereview.chromium.org/1919993002/diff/200001/src/gpu/effects/GrGamm...
src/gpu/effects/GrGammaEffect.h:16: * Creates an effect that applies a gamma
curve.
Doc how src is sampled (always nearest)?

[commit-bot: I haz the power, 2016-04-29 18:29:32]

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

[commit-bot: I haz the power, 2016-04-29 18:29:33]

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

[Brian Osman, 2016-04-29 19:06:22]

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

[commit-bot: I haz the power, 2016-04-29 19:06:32]

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

[commit-bot: I haz the power, 2016-04-29 19:07:43]

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

[commit-bot: I haz the power, 2016-04-29 19:07:45]

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...)
  Build-Ubuntu-GCC-Arm7-Debug-Android-Trybot on client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-GCC-Arm...)

[Brian Osman, 2016-05-02 17:02:42]

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

[commit-bot: I haz the power, 2016-05-02 17:02:51]

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

[commit-bot: I haz the power, 2016-05-02 17:05:20]

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

[commit-bot: I haz the power, 2016-05-02 17:05:22]

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

[Brian Osman, 2016-05-02 21:01:09]

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

[commit-bot: I haz the power, 2016-05-02 21:01:18]

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

[Brian Osman, 2016-05-02 21:02:45]

Better? I can try to get the src/dst rect/point thing working if necessary.

https://codereview.chromium.org/1919993002/diff/200001/include/gpu/GrContext.h
File include/gpu/GrContext.h (right):

https://codereview.chromium.org/1919993002/diff/200001/include/gpu/GrContext....
include/gpu/GrContext.h:302: */
On 2016/04/29 18:27:20, bsalomon wrote:
> Question about this API:
> 
> Can dst and src be different sizes? If so what happens? Should it take a
> srcRect, dstPoint a la copySurface?
> 
> Perhaps we should have some unit tests for this (CopySurfaceTest.cpp might be
a
> decent starting point).

I started trying to support different sizes, but the implementation isn't quite
the same as copySurface (due to different back-end code paths). I can imagine
that people may need that functionality eventually, but I'd rather wait until
it's required. I'm updating the documentation (and code) to make it clear that
it's required for them to be identically sized.

I will add some unit tests, although with the size restriction, the test matrix
will obviously be much smaller.

https://codereview.chromium.org/1919993002/diff/200001/src/gpu/GrContext.cpp
File src/gpu/GrContext.cpp (right):

https://codereview.chromium.org/1919993002/diff/200001/src/gpu/GrContext.cpp#...
src/gpu/GrContext.cpp:548: if (SkScalarNearlyEqual(gamma, 1.0f)) {
On 2016/04/29 18:27:20, bsalomon wrote:
> Maybe just call copySurface here? Should we also detect the case that the src
is
> linear and the dst is srgb and the specified gamma was 2.2 and let the hw do
it?

I tried falling back to copySurface, but that code doesn't enable the
gammaCorrect flag on the deviceContext that it creates. So F16 (offscreen) ->
sRGB (FB0) fails. We pass in gamma 1.0 in that case, expecting the HW to do the
conversion for us. If we use my code, that works (the paint and drawContext are
both flagged gamma correct).

For the second case (detecting other cases where the HW should do the conversion
for us), it's tricky because of the 10-bit case. In that situation, we've
wrapped FB0 in an "sRGB" render target, even though that's only half true. And
when we do the final write, we pass in 2.2, because that's what we need to have
happen. But it's also the case where we need to force the shader to run. The
alternative would be to mark the FB0 render target as non-sRGB in that case, I
guess? That seems like a trap for the unwary user, though.

https://codereview.chromium.org/1919993002/diff/200001/src/gpu/effects/GrGamm...
File src/gpu/effects/GrGammaEffect.h (right):

https://codereview.chromium.org/1919993002/diff/200001/src/gpu/effects/GrGamm...
src/gpu/effects/GrGammaEffect.h:16: * Creates an effect that applies a gamma
curve.
On 2016/04/29 18:27:20, bsalomon wrote:
> Doc how src is sampled (always nearest)?

Done.

https://codereview.chromium.org/1919993002/diff/340001/tests/ApplyGammaTest.cpp
File tests/ApplyGammaTest.cpp (right):

https://codereview.chromium.org/1919993002/diff/340001/tests/ApplyGammaTest.c...
tests/ApplyGammaTest.cpp:100: for (auto gamma : { 1.0f, 1.8f, 2.2f }) {
Tests identity, sRGB and arbitrary gamma (to exercise every code path).

[commit-bot: I haz the power, 2016-05-02 21:16:19]

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

[commit-bot: I haz the power, 2016-05-02 21:16:20]

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

[bsalomon, 2016-05-02 21:17:40]

https://codereview.chromium.org/1919993002/diff/200001/include/gpu/GrContext.h
File include/gpu/GrContext.h (right):

https://codereview.chromium.org/1919993002/diff/200001/include/gpu/GrContext....
include/gpu/GrContext.h:302: */
On 2016/05/02 21:02:45, Brian Osman wrote:
> On 2016/04/29 18:27:20, bsalomon wrote:
> > Question about this API:
> > 
> > Can dst and src be different sizes? If so what happens? Should it take a
> > srcRect, dstPoint a la copySurface?
> > 
> > Perhaps we should have some unit tests for this (CopySurfaceTest.cpp might
be
> a
> > decent starting point).
> 
> I started trying to support different sizes, but the implementation isn't
quite
> the same as copySurface (due to different back-end code paths). I can imagine
> that people may need that functionality eventually, but I'd rather wait until
> it's required. I'm updating the documentation (and code) to make it clear that
> it's required for them to be identically sized.

sgtm

> 
> I will add some unit tests, although with the size restriction, the test
matrix
> will obviously be much smaller.

https://codereview.chromium.org/1919993002/diff/200001/src/gpu/GrContext.cpp
File src/gpu/GrContext.cpp (right):

https://codereview.chromium.org/1919993002/diff/200001/src/gpu/GrContext.cpp#...
src/gpu/GrContext.cpp:548: if (SkScalarNearlyEqual(gamma, 1.0f)) {
On 2016/05/02 21:02:45, Brian Osman wrote:
> On 2016/04/29 18:27:20, bsalomon wrote:
> > Maybe just call copySurface here? Should we also detect the case that the
src
> is
> > linear and the dst is srgb and the specified gamma was 2.2 and let the hw do
> it?
> 
> I tried falling back to copySurface, but that code doesn't enable the
> gammaCorrect flag on the deviceContext that it creates. So F16 (offscreen) ->
> sRGB (FB0) fails. We pass in gamma 1.0 in that case, expecting the HW to do
the
> conversion for us. If we use my code, that works (the paint and drawContext
are
> both flagged gamma correct).

Is that what we want copySurface to do? Maybe we should update it to be gamma
correct.

> 
> For the second case (detecting other cases where the HW should do the
conversion
> for us), it's tricky because of the 10-bit case. In that situation, we've
> wrapped FB0 in an "sRGB" render target, even though that's only half true. And
> when we do the final write, we pass in 2.2, because that's what we need to
have
> happen. But it's also the case where we need to force the shader to run. The
> alternative would be to mark the FB0 render target as non-sRGB in that case, I
> guess? That seems like a trap for the unwary user, though.

We mark the config of the GrRT that wraps the 10bit surface as sRGB? I was
somewhat assuming "srgb" on GrPixelConfig meant a hw-converted format.

[Brian Osman, 2016-05-03 16:01:50]

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

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

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

[Brian Osman, 2016-05-03 16:02:52]

Description was changed from

==========
Added --tenBit option to SampleApp, triggers creation of a ten-bit/channel
buffer. (Only on Windows at the moment). Uses new effect to do the final
gamma adjustment

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

to

==========
Added --deepColor option to SampleApp, triggers creation of a ten-bit/channel
buffer. (Only on Windows at the moment). Uses new effect to do the final
gamma adjustment

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

[commit-bot: I haz the power, 2016-05-03 16:14:06]

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

[commit-bot: I haz the power, 2016-05-03 16:14:07]

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

[Brian Osman, 2016-05-03 20:25:44]

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

[commit-bot: I haz the power, 2016-05-03 20:25:47]

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

[commit-bot: I haz the power, 2016-05-03 20:36:18]

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

[commit-bot: I haz the power, 2016-05-03 20:36:20]

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

[Brian Osman, 2016-05-03 21:00:40]

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

[commit-bot: I haz the power, 2016-05-03 21:00:46]

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

[commit-bot: I haz the power, 2016-05-03 21:10:59]

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

[commit-bot: I haz the power, 2016-05-03 21:11:00]

Dry run: This issue passed the CQ dry run.

[Brian Osman, 2016-05-04 21:10:11]

PTAL, planning to reuse some of this code in another upcoming change...

[bsalomon, 2016-05-05 18:53:46]

lgtm

[Brian Osman, 2016-05-05 18:55:44]

The CQ bit was checked by brianosman@google.com

[commit-bot: I haz the power, 2016-05-05 18:55:56]

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

[commit-bot: I haz the power, 2016-05-05 18:58:26]

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

[commit-bot: I haz the power, 2016-05-05 18:58:30]

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...)

[Brian Osman, 2016-05-05 19:04:38]

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

[commit-bot: I haz the power, 2016-05-05 19:04:45]

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

[Brian Osman, 2016-05-05 19:15:59]

The CQ bit was unchecked by brianosman@google.com

[Brian Osman, 2016-05-05 19:16:01]

The CQ bit was checked by brianosman@google.com

[Brian Osman, 2016-05-05 19:16:02]

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

[commit-bot: I haz the power, 2016-05-05 19:16:07]

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

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

Description was changed from

==========
Added --deepColor option to SampleApp, triggers creation of a ten-bit/channel
buffer. (Only on Windows at the moment). Uses new effect to do the final
gamma adjustment

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

to

==========
Added --deepColor option to SampleApp, triggers creation of a ten-bit/channel
buffer. (Only on Windows at the moment). Uses new effect to do the final
gamma adjustment

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/+/2d1ee7936e3536e45c963db004e3b512bb415fd8
==========

[commit-bot: I haz the power, 2016-05-05 19:24:36]

Committed patchset #24 (id:460001) as
https://skia.googlesource.com/skia/+/2d1ee7936e3536e45c963db004e3b512bb415fd8