TrimMemory strategy while offscreenPreRaster is on.

android_webview/browser/shared_renderer_state.cc

Index: android_webview/browser/shared_renderer_state.cc
diff --git a/android_webview/browser/shared_renderer_state.cc b/android_webview/browser/shared_renderer_state.cc
index 1d9874ee2d6c4962b57588e552183b1b29255d76..8599d6fda467bbc742afb4a630100492cc442be9 100644
--- a/android_webview/browser/shared_renderer_state.cc
+++ b/android_webview/browser/shared_renderer_state.cc
@@ -285,6 +285,15 @@ void SharedRendererState::DrawGL(AwDrawGLInfo* draw_info) {
 }
 
 void SharedRendererState::ReleaseHardwareDrawIfNeededOnUI() {
+  ReleaseCompositorResourcesIfNeededOnUI(false);
+}
+
+void SharedRendererState::DeleteHardwareRendererOnUI() {
+  ReleaseCompositorResourcesIfNeededOnUI(true);
+}
+
+void SharedRendererState::ReleaseCompositorResourcesIfNeededOnUI(
+    bool keep_child_compositor_tiles) {

[boliu, 2015/04/16 01:58:40]

release_hardware_draw?

This class doesn't know anything about tiles

[hush (inactive), 2015/04/16 04:06:25]

Done.

   DCHECK(ui_loop_->BelongsToCurrentThread());
   InsideHardwareReleaseReset auto_inside_hardware_release_reset(this);
 
@@ -300,7 +309,8 @@ void SharedRendererState::ReleaseHardwareDrawIfNeededOnUI() {
       DrawGL(&info);
     }
 
-    browser_view_renderer_->ReleaseHardware();
+    if (!keep_child_compositor_tiles)
+      browser_view_renderer_->ReleaseHardware();
   }
 
   GLViewRendererManager* manager = GLViewRendererManager::GetInstance();
@@ -313,7 +323,7 @@ void SharedRendererState::ReleaseHardwareDrawIfNeededOnUI() {
     }
   }
 
-  if (hardware_initialized) {
+  if (hardware_initialized && !keep_child_compositor_tiles) {

[boliu, 2015/04/16 01:58:40]

Can't skip this (in theory), some other thread can still get hold of the key
from RendererManager, and schedule something synchronous, which needs to be
cleared, ie don't change this line.

[hush (inactive), 2015/04/16 04:06:25]

Removed the additional condition.
What's the situation for this to happen?
You mean something in GPU thread could get hold of the key during
"PerformIdleWork" after hardware renderer destruction and schedule something
synchronous?

     // Flush any invoke functors that's caused by ReleaseHardware.
     browser_view_renderer_->RequestDrawGL(true);
   }