Make CommandBuffer::Flush asynchronous, and add CommandBuffer::FlushSync with former semantics.

gpu/pgl/command_buffer_pepper.cc

Index: gpu/pgl/command_buffer_pepper.cc
diff --git a/gpu/pgl/command_buffer_pepper.cc b/gpu/pgl/command_buffer_pepper.cc
index 0025803de7879fea27743d52be5cc16156578bed..db724744ffc1fc35bc0c77a0488d1606ea4b892c 100644
--- a/gpu/pgl/command_buffer_pepper.cc
+++ b/gpu/pgl/command_buffer_pepper.cc
@@ -83,7 +83,11 @@ CommandBuffer::State CommandBufferPepper::GetState() {
 #endif  // ENABLE_NEW_NPDEVICE_API
 }
 
-CommandBuffer::State CommandBufferPepper::Flush(int32 put_offset) {
+void CommandBufferPepper::Flush(int32 put_offset) {

[apatrick, 2011/01/14 18:31:34]

I think we might want to change PPAPI to make the distinction between sync and
async flushes.

[Antoine Labour, 2011/01/14 21:35:33]

This is old Pepper v1 code. It will go away in a few days, I'm just keeping it
compiling and working semantically.

For PPAPI (Pepper v2) code, the command buffers aren't exposed directly to the
client. All the client has is higher level glFlush, glFinish and other blocking
calls - and possibly fences if we add them. I don't think there's a point in
exposing the "sync" flush as such to the client, but it is currently necessary
for the underlying implementation to avoid busy-waiting (though I want to
replace it with Wait interfaces - e.g. wait-on-get-reaching-that-value or
wait-on-token-reaching-that-value - that would reduce IPC traffic and improve
latency a little bit).

+  FlushSync(put_offset);
+}
+
+CommandBuffer::State CommandBufferPepper::FlushSync(int32 put_offset) {
 #if defined(ENABLE_NEW_NPDEVICE_API)
   int32 input_attribs[] = {
     NP3DAttrib_PutOffset, put_offset,