Add a flag to allow renderer to use software compositor when GL compositor doesn't work.

Add a flag to allow renderer to use software compositor when GL compositor doesn't work.

The --enable-software-compositing flag will allow the renderer to use the software compositor if it can't create a GL context. This is currently accomplished by having the compositor request a "fallback" output surface if the normal output surface can't be initialized (on the impl thread).


BUG=229712, 230120
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=214930

[danakj, 2013-07-25 15:39:09]

I've been planning a way to address this issue that pushes the whole context
recovery/fallback logic out to the embedder. I circulated a design doc the other
week, have you seen it? WDYT of it? Do you think we could do that directly, or
is it better to have the compositor add logic for this and switch it over after?

https://docs.google.com/a/chromium.org/document/d/1YcEU09zkVvg86C05MbLjeKFLIG...

[jbauman, 2013-07-25 23:41:17]

On 2013/07/25 15:39:09, danakj wrote:
> I've been planning a way to address this issue that pushes the whole context
> recovery/fallback logic out to the embedder. I circulated a design doc the
other
> week, have you seen it? WDYT of it? Do you think we could do that directly, or
> is it better to have the compositor add logic for this and switch it over
after?
> 
>
https://docs.google.com/a/chromium.org/document/d/1YcEU09zkVvg86C05MbLjeKFLIG...

That seems pretty reasonable, but I'm not sure what time-scale you want to do
that in. I'd like to be able to use the software compositor for winaura within a
week or two, so we'll need something set up to do this fallback soon.

[danakj, 2013-07-26 01:51:58]

Doing the OutputSurface for mode switching won't be in a week or two time frame
for sure, as I'm starting to wade into content/browser/ refactors to make it
possible.

This has a pretty minimal impact on cc/ so I'm okay with doing something like
this..

Can you add a unit test that verifies |fallback| becomes true if you keep
failing enough times?

[piman, 2013-07-26 03:36:35]

LGTM (+nit) for now, and we can fix with Dana's changes.

https://codereview.chromium.org/19267016/diff/23001/content/public/common/con...
File content/public/common/content_switches.cc (right):

https://codereview.chromium.org/19267016/diff/23001/content/public/common/con...
content/public/common/content_switches.cc:527: const char
kDisableGpuCompositing[] = "disable-gpu-compositing";
nit: can you also add those to kForwardSwitches in
chrome/browser/chromeos/login/chrome_restart_request.cc so that it works on
Chrome OS in guest mode?

[jbauman, 2013-07-27 02:23:48]

Also adding jamesr to do an OWNERS review of webkit\support\

[jamesr, 2013-07-28 23:10:13]

lgtm

[danakj, 2013-07-30 01:04:07]

Thanks for the tests, didn't see you publish this after writing them, but LGTM

https://codereview.chromium.org/19267016/diff/40001/cc/trees/layer_tree_host_...
File cc/trees/layer_tree_host_unittest_context.cc (right):

https://codereview.chromium.org/19267016/diff/40001/cc/trees/layer_tree_host_...
cc/trees/layer_tree_host_unittest_context.cc:269: EXPECT_EQ(8 + 10 + 10 + 1,
num_losses_);
Heh, I should have commented this variable the last time I figured out what all
the numbers were. Oh well..

[commit-bot: I haz the power, 2013-07-31 23:26:12]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jbauman@chromium.org/19267016/51001

[commit-bot: I haz the power, 2013-07-31 23:43:26]

Step "update" is always a major failure.
Look at the try server FAQ for more details.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2013-08-01 00:02:13]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jbauman@chromium.org/19267016/51001

[commit-bot: I haz the power, 2013-08-01 02:46:27]

Change committed as 214930