Enable Canvas2D hardware acceleration for Android WebView

cc/trees/thread_proxy.cc

Index: cc/trees/thread_proxy.cc
===================================================================
--- cc/trees/thread_proxy.cc	(revision 243070)
+++ cc/trees/thread_proxy.cc	(working copy)
@@ -1438,6 +1438,11 @@
   completion->Signal();
 }
 
+void ThreadProxy::OnGetRendererCapabilities() {
+  renderer_capabilities_main_thread_copy_ =
+    layer_tree_host_impl_->GetRendererCapabilities();

[boliu, 2014/01/08 17:55:05]

Much less hacky, still has some problems though.

renderer_capabilities_main_thread_copy_ lives on the main thread (ie the blink
thread). This function is called by LayerTreeHostImpl on the "impl" thread (also
known as the compositor thread). Documentation for this is
http://dev.chromium.org/developers/design-documents/compositor-thread-archite...

So this assignment is not thread safe. The right way would be to post a task to
main thread.

I think this is the right way to go, but this opens up a larger issue that that
main thread copy of the capabilities can get out of sync with the impl thread
copy. So we should do an audit of every renderer capability.

If a cap is not used on main thread at all, then we should not make it
accessible on main thread.
Maybe it's used on the main thread, but never used by webview, in which case we
need to add DCHECKs.
If it is used by webview, then need to make sure that either the inconsistency
is harmless or can be handled in some fashion.

Sounds like something you want to take? I can file a bug and cc you and
compositor owner (who might have different opinion than me)

+}
+
 void ThreadProxy::FinishGLOnImplThread(CompletionEvent* completion) {
   TRACE_EVENT0("cc", "ThreadProxy::FinishGLOnImplThread");
   DCHECK(IsImplThread());