New gamut GM, to test gamut conversion in various code-paths

New gamut GM, to test gamut conversion in various code-paths

After several different strategies, this one appears to work
well. The basic test:

1) For a variety of drawing techniques, we render fixed size
   rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
   WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
   to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
   data, then draw that directly to the final canvas.

So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.

Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png

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

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

[Brian Osman, 2016-08-30 19:45:02]

Description was changed from

==========
New gamut GM, to test gamut conversion in various code-paths

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

to

==========
New gamut GM, to test gamut conversion in various code-paths

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

[Brian Osman, 2016-09-06 19:24:53]

Description was changed from

==========
New gamut GM, to test gamut conversion in various code-paths

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

to

==========
New gamut GM, to test gamut conversion in various code-paths

After several different strategies, this one appears to work
well. The basic test:

1) For a variety of drawing techniques, we render fixed size
   rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
   WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
   to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
   data, then draw that directly to the final canvas.

So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bitmap
paths have that behavior. Adding more test cases (and fixing
the ones that are already incorrect) will be the long tail of
gamut transformation.

Current output (with the dependent patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png

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

[Brian Osman, 2016-09-06 19:25:12]

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

[commit-bot: I haz the power, 2016-09-06 19:25:22]

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

[Brian Osman, 2016-09-06 19:25:34]

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

[commit-bot: I haz the power, 2016-09-06 19:28:32]

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

[commit-bot: I haz the power, 2016-09-06 19:28:33]

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

[Brian Osman, 2016-09-06 19:30:20]

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

[commit-bot: I haz the power, 2016-09-06 19:30:22]

Dry run: 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-09-06 19:38:28]

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

[commit-bot: I haz the power, 2016-09-06 19:38:29]

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

[msarett, 2016-09-06 20:07:54]

https://codereview.chromium.org/2293173002/diff/80001/gm/gamut.cpp
File gm/gamut.cpp (right):

https://codereview.chromium.org/2293173002/diff/80001/gm/gamut.cpp#newcode136
gm/gamut.cpp:136: // readPixels doesn't do color conversion (yet), so we can use
it to see the raw (wide) data
This is fine, but is there another hack to access the pixels?

I've run into trouble before in test code, where I assume something doesn't do
color conversion, then I fix it, then the test doesn't work anymore.

----------------------

Edit: Won't this work fine forever?  You're setting the SkColorSpace on dstInfo
to nullptr.

https://codereview.chromium.org/2293173002/diff/80001/gm/gamut.cpp#newcode206
gm/gamut.cpp:206: for (auto renderer : renderers) {
Can we make these auto deletes or something?

[Brian Osman, 2016-09-06 20:55:53]

Description was changed from

==========
New gamut GM, to test gamut conversion in various code-paths

After several different strategies, this one appears to work
well. The basic test:

1) For a variety of drawing techniques, we render fixed size
   rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
   WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
   to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
   data, then draw that directly to the final canvas.

So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bitmap
paths have that behavior. Adding more test cases (and fixing
the ones that are already incorrect) will be the long tail of
gamut transformation.

Current output (with the dependent patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png

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

to

==========
New gamut GM, to test gamut conversion in various code-paths

After several different strategies, this one appears to work
well. The basic test:

1) For a variety of drawing techniques, we render fixed size
   rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
   WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
   to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
   data, then draw that directly to the final canvas.

So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.

Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png

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

[Brian Osman, 2016-09-07 13:12:22]

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

[commit-bot: I haz the power, 2016-09-07 13:12:32]

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

[Brian Osman, 2016-09-07 13:26:02]

Suppressed this GM in all serialization configs. Removed
dependency on the other Ganesh change, so we can land this
first, then check in the other one to improve the results
on this test.

https://codereview.chromium.org/2293173002/diff/80001/gm/gamut.cpp
File gm/gamut.cpp (right):

https://codereview.chromium.org/2293173002/diff/80001/gm/gamut.cpp#newcode136
gm/gamut.cpp:136: // readPixels doesn't do color conversion (yet), so we can use
it to see the raw (wide) data
On 2016/09/06 20:07:54, msarett wrote:
> This is fine, but is there another hack to access the pixels?
> 
> I've run into trouble before in test code, where I assume something doesn't do
> color conversion, then I fix it, then the test doesn't work anymore.
> 
> ----------------------
> 
> Edit: Won't this work fine forever?  You're setting the SkColorSpace on
dstInfo
> to nullptr.

I don't think we have another way to get at this data. I agree that nullptr
color space will always suppress conversion, so this code is probably going to
keep
working. I just wanted to be clear about current vs. (potential) future changes.

https://codereview.chromium.org/2293173002/diff/80001/gm/gamut.cpp#newcode206
gm/gamut.cpp:206: for (auto renderer : renderers) {
On 2016/09/06 20:07:54, msarett wrote:
> Can we make these auto deletes or something?

Done.

[msarett, 2016-09-07 13:42:20]

lgtm

https://codereview.chromium.org/2293173002/diff/180001/gm/gamut.cpp
File gm/gamut.cpp (right):

https://codereview.chromium.org/2293173002/diff/180001/gm/gamut.cpp#newcode130
gm/gamut.cpp:130: return;
I think if you treat default as RGBA/BGRA, you won't have to blacklist the
serialization tests.

I slightly prefer this approach, but don't feel strongly.  This will be broken
as soon as we add a serialize-f16 etc.

[commit-bot: I haz the power, 2016-09-07 13:53:54]

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

[commit-bot: I haz the power, 2016-09-07 13:53:55]

Dry run: This issue passed the CQ dry run.

[Brian Osman, 2016-09-07 14:03:08]

On 2016/09/07 13:42:20, msarett wrote:
> lgtm
> 
> https://codereview.chromium.org/2293173002/diff/180001/gm/gamut.cpp
> File gm/gamut.cpp (right):
> 
> https://codereview.chromium.org/2293173002/diff/180001/gm/gamut.cpp#newcode130
> gm/gamut.cpp:130: return;
> I think if you treat default as RGBA/BGRA, you won't have to blacklist the
> serialization tests.
> 
> I slightly prefer this approach, but don't feel strongly.  This will be broken
> as soon as we add a serialize-f16 etc.

... just tried it. Actually, the recording canvas also returns nullptr from
onNewSurface, so this method of making offscreen surfaces doesn't work at all.
If we decide we want to add color-space support to saveLayer, then it might
work?

Think I'll just land this version, though.

[Brian Osman, 2016-09-07 14:03:17]

The CQ bit was checked by brianosman@google.com

[commit-bot: I haz the power, 2016-09-07 14:03:27]

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

[msarett, 2016-09-07 14:03:44]

On 2016/09/07 14:03:27, commit-bot: I haz the power wrote:
> CQ is trying da patch. Follow status at
>  
>
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

SGTM

[commit-bot: I haz the power, 2016-09-07 14:04:49]

Description was changed from

==========
New gamut GM, to test gamut conversion in various code-paths

After several different strategies, this one appears to work
well. The basic test:

1) For a variety of drawing techniques, we render fixed size
   rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
   WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
   to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
   data, then draw that directly to the final canvas.

So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.

Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png

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

to

==========
New gamut GM, to test gamut conversion in various code-paths

After several different strategies, this one appears to work
well. The basic test:

1) For a variety of drawing techniques, we render fixed size
   rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
   WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
   to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
   data, then draw that directly to the final canvas.

So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.

Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png

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

Committed:
https://skia.googlesource.com/skia/+/2c4b64e92a3e589764336a91e06cebaa35ba5eb0
==========

[commit-bot: I haz the power, 2016-09-07 14:04:50]

Committed patchset #10 (id:180001) as
https://skia.googlesource.com/skia/+/2c4b64e92a3e589764336a91e06cebaa35ba5eb0