Execute all GL commands up to the put offset reported by a flush.

gpu/command_buffer/client/gles2_implementation.cc

Index: gpu/command_buffer/client/gles2_implementation.cc
===================================================================
--- gpu/command_buffer/client/gles2_implementation.cc	(revision 91774)
+++ gpu/command_buffer/client/gles2_implementation.cc	(working copy)
@@ -800,7 +800,6 @@
   // the scheduler yields between the InsertToken and the SwapBuffers.
   swap_buffers_tokens_.push(helper_->InsertToken());
   helper_->SwapBuffers();
-  helper_->YieldScheduler();
   helper_->CommandBufferHelper::Flush();
   // Wait if we added too many swap buffers.
   if (swap_buffers_tokens_.size() > kMaxSwapBuffers) {
@@ -818,6 +817,16 @@
       client_parent_id);
 }
 
+void GLES2Implementation::ResizeCHROMIUM(GLuint width, GLuint height) {
+  GPU_CLIENT_LOG("[" << this << "] glResizeCHROMIUM("
+      << width << ", " << height << ")");
+  helper_->ResizeCHROMIUM(width, height);
+
+  // ResizeCHROMIUM might unschedule. Make sure it is flushed so that subsequent
+  // commands are not issued out-of-order with other command buffers.
+  helper_->CommandBufferHelper::Flush();

[piman, 2011/07/09 20:40:22]

It took me a while to figure this out, even with the comment...

So, IIUC, you need this because now when the service unschedules, it never goes
back to process remaining commands, until another Flush comes, breaking the
ordering semantics (if another Flush came on another context in the mean time).

I wonder if calling PutChanged from GpuScheduler::SetScheduled would solve that
problem, in a nicer way, because you wouldn't depend on the client to enforce
the semantics.

[jbates, 2011/07/11 18:39:50]

I'm not sure why this Flush is needed. Why does getting unscheduled break
ordering? Sometime after this resize call, the client should issue a glFlush,
and that should maintain proper command ordering with respect to other command
buffers, right? If not, can we fix that so that regardless of
scheduled/unscheduled, client Flushes are always guaranteed to be completed in
order (unless an error occurs).

[apatrick_chromium, 2011/07/11 21:25:45]

It's complicated and confusing and liable to cause breakage in the future. I'll
fix it as piman suggests.

+}
+
 void GLES2Implementation::GenSharedIdsCHROMIUM(
   GLuint namespace_id, GLuint id_offset, GLsizei n, GLuint* ids) {
   GPU_CLIENT_LOG("[" << this << "] glGenSharedIdsCHROMIUMTextures("