cc: Add layer-based pixel tests.

cc: Add layer-based pixel tests.

This adds a test framework for pixel tests based on a layer tree. Included
is a single new pixel test to demonstrate the framework, which is a test
derived from the layout test
platform/chromium/compositing/filters/background-filter-blur.html
reproduced with solid color layers.

New test:
LayerTreeHostFiltersPixelTest.BackgroundFilterBlur

R=jamesr
BUG=191170
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=188262

[danakj, 2013-03-14 00:15:33]

moar tests!

[danakj, 2013-03-14 18:25:55]

This is the png since codereview can't show it ಠ_ಠ 

http://imgur.com/H48SPuZ

[jamesr, 2013-03-14 20:00:45]

https://codereview.chromium.org/12518026/diff/27001/cc/test/layer_tree_pixel_...
File cc/test/layer_tree_pixel_test.cc (right):

https://codereview.chromium.org/12518026/diff/27001/cc/test/layer_tree_pixel_...
cc/test/layer_tree_pixel_test.cc:22:
EXPECT_TRUE(gfx::InitializeGLBindings(gfx::kGLImplementationOSMesaGL));
InitializeGLBindings() doesn't look safe to call multiple times in general, but
createOutputSurface() could be (i.e. if someone writes a lost context pixel
test).  Can we put this somewhere that happens just once?

This should be ASSERT_TRUE() since if it fails we can't proceed with the test

https://codereview.chromium.org/12518026/diff/27001/cc/test/layer_tree_pixel_...
File cc/test/layer_tree_pixel_test.h (right):

https://codereview.chromium.org/12518026/diff/27001/cc/test/layer_tree_pixel_...
cc/test/layer_tree_pixel_test.h:41: // Common CSS colors defined for tests to
use.
third_party/skia/include/core/SkColor already has most of these:


#define SK_ColorTRANSPARENT 0x00000000  //!< transparent SkColor value

#define SK_ColorBLACK       0xFF000000  //!< black SkColor value
#define SK_ColorDKGRAY      0xFF444444  //!< dark gray SkColor value
#define SK_ColorGRAY        0xFF888888  //!< gray SkColor value
#define SK_ColorLTGRAY      0xFFCCCCCC  //!< light gray SkColor value
#define SK_ColorWHITE       0xFFFFFFFF  //!< white SkColor value

#define SK_ColorRED         0xFFFF0000  //!< red SkColor value
#define SK_ColorGREEN       0xFF00FF00  //!< green SkColor value
#define SK_ColorBLUE        0xFF0000FF  //!< blue SkColor value
#define SK_ColorYELLOW      0xFFFFFF00  //!< yellow SkColor value
#define SK_ColorCYAN        0xFF00FFFF  //!< cyan SkColor value
#define SK_ColorMAGENTA     0xFFFF00FF  //!< magenta SkColor value

Why do we need more?

[danakj, 2013-03-14 20:43:50]

https://codereview.chromium.org/12518026/diff/27001/cc/test/layer_tree_pixel_...
File cc/test/layer_tree_pixel_test.cc (right):

https://codereview.chromium.org/12518026/diff/27001/cc/test/layer_tree_pixel_...
cc/test/layer_tree_pixel_test.cc:22:
EXPECT_TRUE(gfx::InitializeGLBindings(gfx::kGLImplementationOSMesaGL));
On 2013/03/14 20:00:46, jamesr wrote:
> InitializeGLBindings() doesn't look safe to call multiple times in general,
but
> createOutputSurface() could be (i.e. if someone writes a lost context pixel
> test).  Can we put this somewhere that happens just once?
> 
> This should be ASSERT_TRUE() since if it fails we can't proceed with the test

Oh ok. I had actually looked in the function and made sure it was safe to call
multiple times (it early outs if the current implementation is not none). Maybe
I looked in the wrong place? It's something we could initialize once forever
instead of once per test tho, I was thinking about that..

https://codereview.chromium.org/12518026/diff/27001/cc/test/layer_tree_pixel_...
File cc/test/layer_tree_pixel_test.h (right):

https://codereview.chromium.org/12518026/diff/27001/cc/test/layer_tree_pixel_...
cc/test/layer_tree_pixel_test.h:41: // Common CSS colors defined for tests to
use.
Yeh, these colors are not the same as web colors and I mostly just didn't want
to use that green cuz it's ugly, and different from layout tests (it's not css
green), and hard to see blending with white clearly since it's so bright.

If you don't really care about using css colors I can just use a custom green in
those tests instead of SK_ColorGREEN since I care about it for them.

[danakj, 2013-03-14 21:33:51]

https://codereview.chromium.org/12518026/diff/27001/cc/test/layer_tree_pixel_...
File cc/test/layer_tree_pixel_test.cc (right):

https://codereview.chromium.org/12518026/diff/27001/cc/test/layer_tree_pixel_...
cc/test/layer_tree_pixel_test.cc:22:
EXPECT_TRUE(gfx::InitializeGLBindings(gfx::kGLImplementationOSMesaGL));
On 2013/03/14 20:43:50, danakj wrote:
> > This should be ASSERT_TRUE() since if it fails we can't proceed with the
test

Can't ASSERT_TRUE unless the return type is void. I'll CHECK instead.

[jamesr, 2013-03-14 21:47:37]

On 2013/03/14 20:43:50, danakj wrote:
>
https://codereview.chromium.org/12518026/diff/27001/cc/test/layer_tree_pixel_...
> File cc/test/layer_tree_pixel_test.cc (right):
> 
>
https://codereview.chromium.org/12518026/diff/27001/cc/test/layer_tree_pixel_...
> cc/test/layer_tree_pixel_test.cc:22:
> EXPECT_TRUE(gfx::InitializeGLBindings(gfx::kGLImplementationOSMesaGL));
> On 2013/03/14 20:00:46, jamesr wrote:
> > InitializeGLBindings() doesn't look safe to call multiple times in general,
> but
> > createOutputSurface() could be (i.e. if someone writes a lost context pixel
> > test).  Can we put this somewhere that happens just once?
> > 
> > This should be ASSERT_TRUE() since if it fails we can't proceed with the
test
> 
> Oh ok. I had actually looked in the function and made sure it was safe to call
> multiple times (it early outs if the current implementation is not none).
Maybe
> I looked in the wrong place? It's something we could initialize once forever
> instead of once per test tho, I was thinking about that..

Oh!  I totally misread them - they do look safe to call multiple times.  Never
mind, then!

> 
>
https://codereview.chromium.org/12518026/diff/27001/cc/test/layer_tree_pixel_...
> File cc/test/layer_tree_pixel_test.h (right):
> 
>
https://codereview.chromium.org/12518026/diff/27001/cc/test/layer_tree_pixel_...
> cc/test/layer_tree_pixel_test.h:41: // Common CSS colors defined for tests to
> use.
> Yeh, these colors are not the same as web colors and I mostly just didn't want
> to use that green cuz it's ugly, and different from layout tests (it's not css
> green), and hard to see blending with white clearly since it's so bright.
> 
> If you don't really care about using css colors I can just use a custom green
in
> those tests instead of SK_ColorGREEN since I care about it for them.

Hmm, I guess if we can't share them no harm in having a completely different
set.  I think it's confusing, though.  What about just having a darkgreen
instead of overriding the whole set?  That will make the tests a bit
inconsistent...

I'm ok either way. Just make sure the test fails in an obvious and immediate way
when gl init fails and LGTM.

[danakj, 2013-03-14 22:54:02]

> Hmm, I guess if we can't share them no harm in having a completely different
> set.  I think it's confusing, though.  What about just having a darkgreen
> instead of overriding the whole set?  That will make the tests a bit
> inconsistent...
> 
> I'm ok either way. Just make sure the test fails in an obvious and immediate
way
> when gl init fails and LGTM.

Ok, I removed the ones that match skia, and called the rest kCSSGreen, etc.
There's no great answer I guess.

[commit-bot: I haz the power, 2013-03-14 22:58:49]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/danakj@chromium.org/12518026/28003

[commit-bot: I haz the power, 2013-03-15 04:57:39]

Change committed as 188262