cc: remove jank instead of checkerboard setting

cc: remove jank instead of checkerboard setting

This was merely a prototyping setting. It turns out (surprise!) that nobody
likes jank, so we can get rid of this.

R=danakj@chromium.org
BUG=none

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=167697

[danakj, 2012-11-12 20:07:11]

You need to change PropagateFlagsToRenderer function thinger too right? How
about the switch in cc/switches.h?

[enne (OOO), 2012-11-12 20:13:12]

On 2012/11/12 20:07:11, danakj wrote:
> You need to change PropagateFlagsToRenderer function thinger too right? How
> about the switch in cc/switches.h?

Oh yeah! Done.

[danakj, 2012-11-12 20:16:40]

LGTM.

[commit-bot: I haz the power, 2012-11-12 20:22:26]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/enne@chromium.org/11377111/4001

[commit-bot: I haz the power, 2012-11-12 20:22:29]

Failed to apply patch for cc/switches.cc:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file cc/switches.cc
  Hunk #1 FAILED at 22.
  1 out of 1 hunk FAILED -- saving rejects to file cc/switches.cc.rej

Patch:       cc/switches.cc
Index: cc/switches.cc
diff --git a/cc/switches.cc b/cc/switches.cc
index
2214c3dba4226654ea42aa8cd8559b41bb976693..e35e78d1812cf041241ea19c2d87cdce8f9424e2
100644
--- a/cc/switches.cc
+++ b/cc/switches.cc
@@ -22,10 +22,6 @@ const char kEnablePerTilePainting[]         =
"enable-per-tile-painting";
 // compositor.
 const char kEnablePinchInCompositor[]       = "enable-pinch-in-compositor";
 
-// When threaded compositing is turned on, wait until the entire frame has
-// content (i.e. jank) instead of showing checkerboards for missing content.
-const char kJankInsteadOfCheckerboard[] = "jank-instead-of-checkerboard";
-
 // Paint content on the compositor thread instead of the main thread.
 const char kImplSidePainting[] = "impl-side-painting";

[enne (OOO), 2012-11-13 18:42:26]

+sky for content/browser OWNERS

[aelias_OOO_until_Jul13, 2012-11-13 19:05:52]

We were planning to use this for Android WebView.  Some embedders like to
suddenly scroll and then take a screenshot of the WebView, so this setting would
allow us to not show checkerboard in that case.

[danakj, 2012-11-13 19:11:08]

On 2012/11/13 19:05:52, aelias wrote:
> We were planning to use this for Android WebView.  Some embedders like to
> suddenly scroll and then take a screenshot of the WebView, so this setting
would
> allow us to not show checkerboard in that case.

Wouldn't the readback cause a force draw, which would have checkerboards anyway?

[aelias_OOO_until_Jul13, 2012-11-13 19:19:00]

We're going to have to arrange everything so that we can get content-pixels in
every case where apps expect it, even if it means blocking the browser on the
renderer.  It's one of the big headaches associated with WebView.  Anyway, if
there are no other users of this flag, maybe we can accrue our weird WebView
logic to it.

[danakj, 2012-11-13 19:24:34]

On 2012/11/13 19:19:00, aelias wrote:
> We're going to have to arrange everything so that we can get content-pixels in
> every case where apps expect it, even if it means blocking the browser on the
> renderer.  It's one of the big headaches associated with WebView.  Anyway, if
> there are no other users of this flag, maybe we can accrue our weird WebView
> logic to it.

Huh, ya it sounds like we'll need to change readback behaviour to deal with that
regardless.

[enne (OOO), 2012-11-13 19:50:18]

If you need this functionality, I think doing it through a setting is not the
way to get this behavior.

[sky, 2012-11-13 21:57:24]

LGTM

[commit-bot: I haz the power, 2012-11-13 22:00:04]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/enne@chromium.org/11377111/11001

[commit-bot: I haz the power, 2012-11-13 23:22:20]

Retried try job too often for step(s) browser_tests