Global GPU memory manager for android webview

android_webview/native/aw_contents.cc

Index: android_webview/native/aw_contents.cc
diff --git a/android_webview/native/aw_contents.cc b/android_webview/native/aw_contents.cc
index eb009e93f993a5e3e72206ab20d58de911af8f47..ac607d8082a831092400e9351dc84e82ae87c7e7 100644
--- a/android_webview/native/aw_contents.cc
+++ b/android_webview/native/aw_contents.cc
@@ -1051,16 +1051,16 @@ void AwContents::TrimMemoryOnRenderThread(JNIEnv* env,
                                           jboolean visible) {
   if (hardware_renderer_) {
     if (hardware_renderer_->TrimMemory(level, visible)) {
-      content::BrowserThread::PostTask(
-          content::BrowserThread::UI,
+      BrowserThread::PostTask(
+          BrowserThread::UI,
           FROM_HERE,
-          base::Bind(&AwContents::ForceFakeComposite, ui_thread_weak_ptr_));
+          base::Bind(&AwContents::TrimMemory, ui_thread_weak_ptr_));
     }
   }
 }
 
-void AwContents::ForceFakeComposite() {
-  browser_view_renderer_.ForceFakeCompositeSW();
+void AwContents::TrimMemory() {
+  browser_view_renderer_.TrimMemory();

[boliu, 2014/04/28 22:22:15]

This might be out of scope for this patch, but can you try this?

Move everything in HardwareRenderer::TrimMemory directly into BVR, call it
directly on UI thread, and test if it works (ie doesn't deadlock)? I think it
shouldn't deadlock but you never know...

Also another idea. What if TrimMemory goes to GlobalTileManager instead of BVR?
Is GlobalTileManager able to make better decisions about what to do?

[hush (inactive), 2014/04/30 20:50:17]

I put trim memory into BVR.
Haven't thought about putting it into GlobalTileManager yet. Right now, every
webview will lose all tiles during trim memory. If we need to trim less memory
and keep some tiles for some webviews, then we will need to do it
GlobalTileManager. But I don't think this is necessary in near future.

On 2014/04/28 22:22:15, boliu wrote:

 }
 
 void SetShouldDownloadFavicons(JNIEnv* env, jclass jclazz) {