Call set_unblock(true) on async resize message to guarantee its

processing order relative to sync messages, in particular flush on
behalf of SwapBuffers, in the GPU process. This fixes a race condition
in WebGL initialization where the back buffer would sometimes not be
resized properly. Thanks to jam for the suggestion for this fix.

Tested manually by reloading the WebGL image-texture-test demo over
100 times and ensuring it displayed properly each time.

BUG=42733
TEST=none

Review URL: http://codereview.chromium.org/1914005

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46545 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 15 insertions, 1 deletions

diff --git a/chrome/renderer/command_buffer_proxy.cc b/chrome/renderer/command_buffer_proxy.cc
index 917337b..76fea60 100644
--- a/chrome/renderer/command_buffer_proxy.cc
+++ b/chrome/renderer/command_buffer_proxy.cc
@@ -184,7 +184,21 @@ void CommandBufferProxy::SetParseError(
 }
 
 void CommandBufferProxy::ResizeOffscreenFrameBuffer(const gfx::Size& size) {
-  Send(new GpuCommandBufferMsg_ResizeOffscreenFrameBuffer(route_id_, size));
+  IPC::Message* message =
+      new GpuCommandBufferMsg_ResizeOffscreenFrameBuffer(route_id_, size);
+  // We need to set the unblock flag on this message to guarantee the
+  // order in which it is processed in the GPU process. Ordinarily in
+  // certain situations, namely if a synchronous message is being
+  // processed, other synchronous messages may be processed before
+  // asynchronous messages. During some page reloads WebGL seems to
+  // send three messages (sync, async, sync) in rapid succession in
+  // that order, and the sync message (GpuCommandBufferMsg_Flush, on
+  // behalf of SwapBuffers) is sometimes processed before the async
+  // message (GpuCommandBufferMsg_ResizeOffscreenFrameBuffer). This
+  // causes the WebGL content to disappear because the back buffer is
+  // not correctly resized.
+  message->set_unblock(true);
+  Send(message);
 }
 
 #if defined(OS_MACOSX)