Next steps:
1. Stop turning off can_render_to_separate_surface in webview
2. Ship to stable
3. See if anything explodes
4. Remove it all.

+aelias in case he remembers any other blockers. I only remember mixing resources (not a problem now) and performance (hopefully no one cares anymore)

we should give google books a heads up. they are the only user of webview draws that we actually care about. maybe give them a build and let me play with it see if anything gets too slow

Step 1: https://codereview.chromium.org/2698793002/
Step 4: https://codereview.chromium.org/2693703010/

> Originally chrome webview just dropped any content in a render surface. This matched webview behaviour pre-chrome.

No, Jellybean WebView had Chromium WebView's current behavior with can_render_to_separate_surface=false.  Some apps included some pointless CSS with no-op "preserve3d" on their entire content, and simply drawing black in those cases was reported as a regression.

Anyway, if render-surfacy stuff is believed to draw exactly the same results as Chrome would even in resourceless software draw mode nowadays, SGTM to remove this flag.  We'll keep an ear out for complaints about bad performance, or bad "correctness" (certain HTML which was designed to only ever be viewed in a WebView, could have come to rely on the non-render-surface behavior).  But both of those risks are fairly low.

M-58 would include Step 1.

When that gets to stable, we'll have cut M-59 already, as we will have an M-59 beta waiting on the stable promotion.

So M-60 should be Step 4 if all goes well.

OK Thanks for the clarification aelias!

M-60 RBB to make sure I don't forget :3

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e9cf581d97cce0939cc6ce4f1a60767a8a28602f

commit e9cf581d97cce0939cc6ce4f1a60767a8a28602f
Author: danakj <danakj@chromium.org>
Date: Thu Feb 16 22:22:55 2017

cc: Enable use of render surfaces for Android WebView

This was disabled because the compositor was in GL mode making
allocating and using software resources for a software draw very
awkward. Now the software draws are delegated to a separate
cc::Display instance which is completely independent and able
to deal with allocating and using software resources without being
problematic.

It's also possible that using render surfaces (which also allows)
composited effects such as filters will cause a performance problem.
This seems unlikely as all of these same effects can be done during
painting, however. This patch is a minimal one to just change the
behaviour to allowing render surfaces in order to verify things
don't all fall apart. The code to support it can be removed later.

R=boliu@chromium.org, aelias@chromium.org
BUG= 692780 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2698793002
Cr-Commit-Position: refs/heads/master@{#451117}

[modify] https://crrev.com/e9cf581d97cce0939cc6ce4f1a60767a8a28602f/cc/trees/layer_tree_host_unittest.cc
[modify] https://crrev.com/e9cf581d97cce0939cc6ce4f1a60767a8a28602f/cc/trees/layer_tree_impl.cc
[modify] https://crrev.com/e9cf581d97cce0939cc6ce4f1a60767a8a28602f/content/renderer/android/synchronous_compositor_frame_sink.cc
[modify] https://crrev.com/e9cf581d97cce0939cc6ce4f1a60767a8a28602f/content/renderer/android/synchronous_compositor_frame_sink.h
[modify] https://crrev.com/e9cf581d97cce0939cc6ce4f1a60767a8a28602f/content/renderer/render_thread_impl.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dc24211f2acd2182ec5ab009fcc03d8f448169d8

commit dc24211f2acd2182ec5ab009fcc03d8f448169d8
Author: danakj <danakj@chromium.org>
Date: Tue May 09 18:58:25 2017

cc: Remove support for disabling non-root render surfaces.

This mode was used by Android Webview to have everything draw into
the root surface. However, the mode is no longer used making this
code all dead as of https://codereview.chromium.org/2698793002/.

Historically this mode existed because the compositor was in GL mode
making allocating and using software resources for a software draw
very awkward. Now the software draws are delegated to a separate
cc::Display instance which is completely independent and able
to deal with allocating and using software resources without being
problematic.

R=ajuma@chromium.org, weiliangc@chromium.org
BUG= 692780 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2693703010
Cr-Commit-Position: refs/heads/master@{#470399}

[modify] https://crrev.com/dc24211f2acd2182ec5ab009fcc03d8f448169d8/cc/layers/layer_impl.cc
[modify] https://crrev.com/dc24211f2acd2182ec5ab009fcc03d8f448169d8/cc/output/bsp_tree_perftest.cc
[modify] https://crrev.com/dc24211f2acd2182ec5ab009fcc03d8f448169d8/cc/trees/draw_property_utils.cc
[modify] https://crrev.com/dc24211f2acd2182ec5ab009fcc03d8f448169d8/cc/trees/draw_property_utils.h
[modify] https://crrev.com/dc24211f2acd2182ec5ab009fcc03d8f448169d8/cc/trees/layer_tree_host.cc
[modify] https://crrev.com/dc24211f2acd2182ec5ab009fcc03d8f448169d8/cc/trees/layer_tree_host_common.cc
[modify] https://crrev.com/dc24211f2acd2182ec5ab009fcc03d8f448169d8/cc/trees/layer_tree_host_common.h
[modify] https://crrev.com/dc24211f2acd2182ec5ab009fcc03d8f448169d8/cc/trees/layer_tree_host_common_perftest.cc
[modify] https://crrev.com/dc24211f2acd2182ec5ab009fcc03d8f448169d8/cc/trees/layer_tree_host_common_unittest.cc
[modify] https://crrev.com/dc24211f2acd2182ec5ab009fcc03d8f448169d8/cc/trees/layer_tree_impl.cc
[modify] https://crrev.com/dc24211f2acd2182ec5ab009fcc03d8f448169d8/cc/trees/property_tree.cc
[modify] https://crrev.com/dc24211f2acd2182ec5ab009fcc03d8f448169d8/cc/trees/property_tree.h