Adding more cc pixel tests using blend modes.

Adding more cc pixel tests using blend modes.

These tests should cover testing for each type of shader in render
passes: anti-aliasing x masking x filters_color_matrix x renderer_type

Each test validates
- each blend mode with opaque colors
- a coefficient based blend mode (screen) with transparent content and
  with transparency on blending layer
- a shader based blend mode with transparent content and with
  transparency on blending layer

The expectations for GL and for software renderers are stored in
separate files for the moment. There are several blending issues in both
GL and SW renderers causing the results to be different:
- filters and blending don't work well together in the software renderer.
- layers with transparent content having saturation or luminosity blend
  modes give wrong results.

I will file a bug to fix these errors and I will adjust tests afterwards.

BUG=

[rosca, 2014-09-29 14:48:20]

rosca@adobe.com changed reviewers:
+ enne@chromium.org

[rosca, 2014-09-30 17:47:59]

@enne, what do you think about this patch?

[enne (OOO), 2014-10-07 19:57:58]

I'm not super keen on having different software and hardware outputs unless it's
really needed.  How different are the results?  Can a fuzzy pixel detector work
on the same image for both?

Also, if the software one doesn't work for some cases, then maybe split out
these tests more into something where it can be disabled for software?

https://codereview.chromium.org/598593005/diff/40001/cc/trees/layer_tree_host...
File cc/trees/layer_tree_host_pixeltest_blending.cc (right):

https://codereview.chromium.org/598593005/diff/40001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_pixeltest_blending.cc:161:
rotation.RotateAboutZAxis(5.0);
There's already some pixel tests for general antialiasing and render passes. 
What code changes related to blend modes when antialiasing occurs?  Is this a
configuration that needs specific testing?

[rosca, 2014-10-07 21:30:29]

Thanks for the review!

> I'm not super keen on having different software and hardware outputs unless
it's
> really needed.  How different are the results?  Can a fuzzy pixel detector
work
> on the same image for both?
> Also, if the software one doesn't work for some cases, then maybe split out
> these tests more into something where it can be disabled for software?

The software renderer seems to output the right results at this point, therefore
they don't have a suffix.
The differences in the current implementation of GL renderer are too big to be
covered by a decent fuzzy pixel detector:
* for antialiasing tests, the back and forth transformation of the backdrop
causes many differences at the layer edges
* for color matrix tests, the results are wrong now: filters should be applied
before blending the content with the backdrop, but now it happens otherwise
(when filters can be implemented with a color matrix in shaders).
* some differences for non sep blend modes when the backdrop is transparent,
didn't figure it out yet why.

The final goal is definitely to have the same output for both sw and gl, but now
I think they are useful by handling regressions. If you don't agree, I can just
disable GL tests until we fix all these issues.

https://codereview.chromium.org/598593005/diff/40001/cc/trees/layer_tree_host...
File cc/trees/layer_tree_host_pixeltest_blending.cc (right):

https://codereview.chromium.org/598593005/diff/40001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_pixeltest_blending.cc:161:
rotation.RotateAboutZAxis(5.0);
On 2014/10/07 19:57:58, enne wrote:
> There's already some pixel tests for general antialiasing and render passes. 
> What code changes related to blend modes when antialiasing occurs?  Is this a
> configuration that needs specific testing?

These tests are going to cover each type of shader that can be set on a render
pass. We already have tests for antialiasing, but only this test will touch the
blending code inside the antialiasing shader.

[enne (OOO), 2014-10-13 21:46:55]

Re: antialiasing tests.  Do you think it's possible to come up with an aa
condition such that the non-aa results can still be used? Right now you're using
rotation, which is a bit messy and is definitely going to have differences
between hardware and software and is much more likely to churn results over time
than something that lines up with pixels.

I might be overthinking this.  For example, we also aa if all the boundaries of
the quad do not line up with integers.  It seems possible that if you have like
a n pixel clip, then you could draw into a 2n+1-sized SkCanvas with a scale
factor of 2 applied, and then draw the quad with an 0.5 draw transform.  This'll
make that last not-drawn pixel not line up with integer boundaries, but
hopefully the same pixels would be generated for aa and not aa shaders.

Alternatively, I'd be ok with a setting that just said "aa everything you can"
for testing.  (It'd probably be worth doing hacking this in first to see if the
same pixels end up with and without aa).

[danakj, 2014-10-14 18:29:20]

On Mon, Oct 13, 2014 at 5:46 PM, <enne@chromium.org> wrote:

> Re: antialiasing tests.  Do you think it's possible to come up with an aa
> condition such that the non-aa results can still be used? Right now you're
> using
> rotation, which is a bit messy and is definitely going to have differences
> between hardware and software and is much more likely to churn results
> over time
> than something that lines up with pixels.
>
> I might be overthinking this.  For example, we also aa if all the
> boundaries of
> the quad do not line up with integers.  It seems possible that if you have
> like
> a n pixel clip, then you could draw into a 2n+1-sized SkCanvas with a scale
> factor of 2 applied, and then draw the quad with an 0.5 draw transform.
> This'll
> make that last not-drawn pixel not line up with integer boundaries, but
> hopefully the same pixels would be generated for aa and not aa shaders.
>
> Alternatively, I'd be ok with a setting that just said "aa everything you
> can"
> for testing.  (It'd probably be worth doing hacking this in first to see
> if the
> same pixels end up with and without aa).
>

"aa everything for testing" sounds better to me, than making a complicated
scenario that will be hard to read and understand. I think.

FWIW the background filter pixel tests use AA. I was going to say we get by
there with just a fuzzy comparator, but apparently we only run those with
GL renderer also :(

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[rosca, 2014-10-16 16:17:40]

I moved the pixel tests to https://codereview.chromium.org/658483003/.