GLInProcessContext: support async flushes and dedicated GPU thread

android_webview/browser/in_process_view_renderer.cc

Index: android_webview/browser/in_process_view_renderer.cc
diff --git a/android_webview/browser/in_process_view_renderer.cc b/android_webview/browser/in_process_view_renderer.cc
index 2b60bea7e39de5275359f49ba18a9bf938b72066..d2ba2313087bc3ead3cdc09069a87376e7dd322a 100644
--- a/android_webview/browser/in_process_view_renderer.cc
+++ b/android_webview/browser/in_process_view_renderer.cc
@@ -12,10 +12,13 @@
 #include "base/android/jni_android.h"
 #include "base/command_line.h"
 #include "base/debug/trace_event.h"
+#include "base/lazy_instance.h"
 #include "base/logging.h"
 #include "base/strings/stringprintf.h"
+#include "base/threading/thread_local.h"
 #include "content/public/browser/android/synchronous_compositor.h"
 #include "content/public/browser/web_contents.h"
+#include "gpu/command_buffer/service/in_process_command_buffer.h"
 #include "skia/ext/refptr.h"
 #include "third_party/skia/include/core/SkBitmap.h"
 #include "third_party/skia/include/core/SkCanvas.h"
@@ -124,8 +127,35 @@ bool g_is_skia_version_compatible = false;
 
 const int64 kFallbackTickTimeoutInMilliseconds = 500;
 
+base::LazyInstance<ThreadLocalBoolean>::Leaky tls_gl_allowed =

[joth, 2013/07/27 02:24:32]

 does this need to be TLS? there's (currently) a limited number of TLS slots
available ~60.

Seems we could just do:-

// Only touched on UI thread.
bool g_currently_in_draw_gl = false;

void ScheduleGpuWork() {
  if (BrowserThread::CurrentlyOn(BrowserThread::UI) && g_currently_in_draw_gl)
    ...
  else
    .. TODO


...
void DrawGL() {
  DCHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));
  base::AutoReset in_draw_gl_reset(g_currently_in_draw_gl, true);  // don't even
need the ScopedAllow class :-)
  ...

[no sievers, 2013/07/30 00:55:34]

Done.

+    LAZY_INSTANCE_INITIALIZER;
+
+class ScopedAllowGL {
+ public:
+  ScopedAllowGL();
+  ~ScopedAllowGL();
+};
+
+ScopedAllowGL::ScopedAllowGL() {
+  DCHECK(!tls_gl_allowed.Get().Get());
+  tls_gl_allowed.Get().Set(true);
+}
+
+ScopedAllowGL::~ScopedAllowGL() {
+  tls_gl_allowed.Get().Set(false);
+}
+
 }  // namespace
 
+// Called from different threads!
+static void ScheduleGpuWork() {
+  if (tls_gl_allowed.Get().Get()) {
+    gpu::InProcessCommandBuffer::ProcessGpuWorkOnCurrentThread();
+  } else {
+    // TODO: We need to request a callback with a GL context current here.

[joth, 2013/07/27 02:24:32]

this is pretty important right - is there a bug for it? (I can open if there
isn't)

[no sievers, 2013/07/30 00:55:34]

I think Bo might already be working on a patch for this.

+  }
+}
+
 // static
 void BrowserViewRenderer::SetAwDrawSWFunctionTable(
     AwDrawSWFunctionTable* table) {
@@ -134,6 +164,9 @@ void BrowserViewRenderer::SetAwDrawSWFunctionTable(
       g_sw_draw_functions->is_skia_version_compatible(&SkGraphics::GetVersion);
   LOG_IF(WARNING, !g_is_skia_version_compatible)
       << "Skia versions are not compatible, rendering performance will suffer.";
+
+  gpu::InProcessCommandBuffer::SetScheduleCallback(
+      base::Bind(&ScheduleGpuWork));
 }
 
 // static
@@ -227,6 +260,8 @@ void InProcessViewRenderer::DrawGL(AwDrawGLInfo* draw_info) {
   }
 
   ScopedAppGLStateRestore state_restore(ScopedAppGLStateRestore::MODE_DRAW);
+  gpu::InProcessCommandBuffer::ProcessGpuWorkOnCurrentThread();
+  ScopedAllowGL allow_gl;
 
   if (attached_to_window_ && compositor_ && !hardware_initialized_) {
     TRACE_EVENT0("android_webview", "InitializeHwDraw");
@@ -457,6 +492,8 @@ void InProcessViewRenderer::OnDetachedFromWindow() {
 
     ScopedAppGLStateRestore state_restore(
         ScopedAppGLStateRestore::MODE_DETACH_FROM_WINDOW);
+    gpu::InProcessCommandBuffer::ProcessGpuWorkOnCurrentThread();
+    ScopedAllowGL allow_gl;
     compositor_->ReleaseHwDraw();
     hardware_initialized_ = false;
   }