Re-enable solid background color optimization for composited layers.

Re-enable solid background color optimization for composited layers.

This has two parts:
1.) Make GraphicsLayer::setContentsToSolidColor() handle a solid color layer.
2.) Remove GraphicsLayer::supportsBackgroundColorContent() because we have only
one compositor implementation.

BUG=114658, 232846
TEST=compositing/background-color/background-color-change-to-text.html
compositing/background-color/background-color-change-to-transparent.html
compositing/background-color/*

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=162737

[dshwang, 2013-11-19 16:42:55]

https://codereview.chromium.org/14407003 disabled solid background color
optimization because of issue 232846.

And then, jamesr@ find the solution:
https://code.google.com/p/chromium/issues/detail?id=114658#c28
05:40 (jamesr) had to revert only because i forgot to clear 
               GraphicsLayer::m_contentsLayer and ::m_contentsLayerId when 
               removing the solid color layer

So, this CL re-enable solid background color optimization.

To handle m_contentsLayer and m_contentsLayerId, I reuse setContentsTo() like
setContentsToNinePatch(),
setContentsToCanvas(), and setContentsToMedia().

This CL is physically blocked on https://codereview.chromium.org/75113003/

[jamesr, 2013-11-21 21:02:11]

Would any of these tests catch the original regression?

[dshwang, 2013-11-22 12:19:04]

On 2013/11/21 21:02:11, jamesr wrote:
> Would any of these tests catch the original regression?

I agree that we need it. I'll make a test.

In detail, the test will check as follows:
1. first of all, the given layer is solid color layer.
2. add a child element to the renderer that is owner of the given layer.
3. the given layer is not solid color layer anymore.
4. check if rendering is correct.

[dshwang, 2013-11-22 18:47:21]

Currently, Issue 232846 can not be reproduced even with the patch that is
reverted from https://codereview.chromium.org/14333021

I improve one test and add one test.

this is improved :
compositing/background-color/background-color-change-to-text.html 
this test check what I described in msg #3

this is added :
compositing/background-color/background-color-change-to-transparent.html 
this test check that solid color layer's color becomes transparent.

I tried to change graphics layer from solid color layer to direct img layer or
canvas layer, but it is not possible because tag name is different.

If you have good idea for test, please let me know.

[dshwang, 2013-11-22 18:49:48]

https://codereview.chromium.org/63943006/diff/60001/LayoutTests/TestExpectations
File LayoutTests/TestExpectations (right):

https://codereview.chromium.org/63943006/diff/60001/LayoutTests/TestExpectati...
LayoutTests/TestExpectations:326: crbug.com/114658
virtual/softwarecompositing/transitions/scale-transition-no-start.html [
NeedsRebaseline ]
All tests have minor pixel changes.

[jamesr, 2013-11-22 22:18:55]

On 2013/11/22 18:47:21, dshwang wrote:
> Currently, Issue 232846 can not be reproduced even with the patch that is
> reverted from https://codereview.chromium.org/14333021
> 
> I improve one test and add one test.
> 
> this is improved :
> compositing/background-color/background-color-change-to-text.html 
> this test check what I described in msg #3
> 
> this is added :
> compositing/background-color/background-color-change-to-transparent.html 
> this test check that solid color layer's color becomes transparent.
> 
> I tried to change graphics layer from solid color layer to direct img layer or
> canvas layer, but it is not possible because tag name is different.
> 

The original regression was with a plugin.  You could possibly trigger this with
a <canvas> element since the compositing trigger is tied to the canvas element's
context, and thus before the getContext('2d') or getContext('webgl') call the
element won't be composited for that reason, but perhaps not.

> If you have good idea for test, please let me know.

[jamesr, 2013-11-22 22:26:58]

Patch lgtm - this is great. Let's keep a careful eye out for regression but I
expect this to be a big perf win on some pages since we don't have to do any
rasterization or texture uploads.

[dshwang, 2013-11-25 09:53:09]

On 2013/11/22 22:18:55, jamesr wrote:
> > I tried to change graphics layer from solid color layer to direct img layer
or
> > canvas layer, but it is not possible because tag name is different.
> > 
> 
> The original regression was with a plugin.  You could possibly trigger this
with
> a <canvas> element since the compositing trigger is tied to the canvas
element's
> context, and thus before the getContext('2d') or getContext('webgl') call the
> element won't be composited for that reason, but perhaps not.

I add new test for this:
compositing/webgl/webgl-with-accelerated-background-color.html
It check fors compositing WebGL layer and accelerated background-color layer.
On load, there is not WebGL layer because I don't make WebGL context. WebGL
layer is created on the fly.


On 2013/11/22 22:26:58, jamesr wrote:
> Patch lgtm - this is great. Let's keep a careful eye out for regression but I
> expect this to be a big perf win on some pages since we don't have to do any
> rasterization or texture uploads.

Thank you for lgtm. I'll keep eyes out for regression.

Could you review again, especially new test
compositing/webgl/webgl-with-accelerated-background-color.html ?

[jamesr, 2013-11-26 06:07:59]

It looks like a good test.  I'm not sure I really understand the setTimeout()s -
is the idea to force compositing to be evaluated without the webgl layer, then
with it, then once again?  If so I think Shawn has added or is adding explicit
hooks to window.internals to control compositing trigger re-evaluation which
will be more dependable than relying on setTimeout()s to make sure we hit the
right incremental codepaths.

https://codereview.chromium.org/63943006/diff/390001/LayoutTests/compositing/...
File LayoutTests/compositing/webgl/webgl-with-accelerated-background-color.html
(right):

https://codereview.chromium.org/63943006/diff/390001/LayoutTests/compositing/...
LayoutTests/compositing/webgl/webgl-with-accelerated-background-color.html:6:
<style type="text/css" media="screen">
the 'type' and 'media' attributes here aren't strictly necessary

[dshwang, 2013-11-26 07:46:11]

On 2013/11/26 06:07:59, jamesr wrote:
> It looks like a good test.  I'm not sure I really understand the setTimeout()s
-
> is the idea to force compositing to be evaluated without the webgl layer, then
> with it, then once again?

The intention is as follows:
1) compositing to be evaluated without the webgl layer <- onLoad
2) then with the webgl layer <- first setTimeout
3) then read pixel to compare with expected html <- second setTimeout


> If so I think Shawn has added or is adding explicit
> hooks to window.internals to control compositing trigger re-evaluation which
> will be more dependable than relying on setTimeout()s to make sure we hit the
> right incremental codepaths.

I think my intention is slightly different from what you understood. Do you
think setTimeout() is not enough?

@shawnsingh Is there a window.internals hook to trigger re-evaluation of
compositing layers?


>
https://codereview.chromium.org/63943006/diff/390001/LayoutTests/compositing/...
> File
LayoutTests/compositing/webgl/webgl-with-accelerated-background-color.html
> (right):
> 
>
https://codereview.chromium.org/63943006/diff/390001/LayoutTests/compositing/...
> LayoutTests/compositing/webgl/webgl-with-accelerated-background-color.html:6:
> <style type="text/css" media="screen">
> the 'type' and 'media' attributes here aren't strictly necessary

Thank you. I'll update.
Anyway, webgl-background-color.html needs to get rid of the 'type' and 'media'
attributes also. I'll do it later.

[dshwang, 2013-11-26 11:49:00]

https://codereview.chromium.org/63943006/diff/430001/LayoutTests/compositing/...
File LayoutTests/compositing/webgl/webgl-with-accelerated-background-color.html
(right):

https://codereview.chromium.org/63943006/diff/430001/LayoutTests/compositing/...
LayoutTests/compositing/webgl/webgl-with-accelerated-background-color.html:40:
window.internals.forceCompositingUpdate(document);
@jamesr, I add this line to ensure re-evaluating compositing layers. It helps to
avoid flaky test.

[jamesr, 2013-11-26 18:19:15]

On 2013/11/26 11:49:00, dshwang wrote:
>
https://codereview.chromium.org/63943006/diff/430001/LayoutTests/compositing/...
> File
LayoutTests/compositing/webgl/webgl-with-accelerated-background-color.html
> (right):
> 
>
https://codereview.chromium.org/63943006/diff/430001/LayoutTests/compositing/...
> LayoutTests/compositing/webgl/webgl-with-accelerated-background-color.html:40:
> window.internals.forceCompositingUpdate(document);
> @jamesr, I add this line to ensure re-evaluating compositing layers. It helps
to
> avoid flaky test.

Looks great!

[commit-bot: I haz the power, 2013-11-26 20:00:15]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dongseong.hwang@intel.com/63943006/430001

[commit-bot: I haz the power, 2013-11-27 08:37:40]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dongseong.hwang@intel.com/63943006/430001

[commit-bot: I haz the power, 2013-11-27 09:40:10]

Change committed as 162737