Add command buffer support for GL_RGB CHROMIUM image emulation.

gpu/GLES2/extensions/CHROMIUM/CHROMIUM_gpu_memory_buffer_image.txt

Index: gpu/GLES2/extensions/CHROMIUM/CHROMIUM_gpu_memory_buffer_image.txt
diff --git a/gpu/GLES2/extensions/CHROMIUM/CHROMIUM_gpu_memory_buffer_image.txt b/gpu/GLES2/extensions/CHROMIUM/CHROMIUM_gpu_memory_buffer_image.txt
index d185894ade76ac4ea93c0167e11923c7c1e281a1..7a8e8aff63eb1b46991fbfb72d793f34f692626b 100644
--- a/gpu/GLES2/extensions/CHROMIUM/CHROMIUM_gpu_memory_buffer_image.txt
+++ b/gpu/GLES2/extensions/CHROMIUM/CHROMIUM_gpu_memory_buffer_image.txt
@@ -51,6 +51,13 @@ New Procedures and Functions
 
     INVALID_ENUM is generated if <usage> is not READ_WRTIE_CHROMIUM.
 
+    On OS X, driver bugs prevent the usage of memory buffers with RGB internal
+    format. As a workaround, the created GpuMemoryBuffer will always have
+    internal format RGBA. The caller is responsible for handling this
+    appropriately. The only support provided by this extension is that calls to
+    copyTexImage2D and copyTexSubImage2D will perform paramter validation as if
+    the internal format were RGB.

[piman, 2016/04/14 01:05:43]

How is the client supposed to know? Does this mean we'll have #ifdefs OS_MACOSX
to deal with this? Can we instead at least add a cap bit (in gpu::Capabilities)
/ extension string to explain when the workaround is in place?

[piman, 2016/04/14 01:05:43]

Actually, it looks like ReadPixels is affected too.

[erikchen, 2016/04/14 01:20:10]

For reference, this is the companion CL that implements the client side
workaround:
https://codereview.chromium.org/1856933002/

There's already an #ifdef OS_MACOSX, because the target needs to be RECTANGLE
instead of 2D. If you want, we could expose 2 capabilities, one for RGB
workaround, and one for RECTANGLE instead of 2D, and then we could remove the
#ifdef from DrawingBuffer.cpp

[erikchen, 2016/04/14 21:24:46]

I started adding a capability, but I couldn't find a good mechanism for passing
capabilities through to WebKit. Right now, most flags that alter behavior get
passed in during WebKit initialization in the form of WebRuntimeFeatures. I
guess we could add a new public API, or somehow expose the capability through
OpenGL interface, but neither of those sounds very appealing, given that all
we're really doing is plumbing an #ifdef from gpu/command_buffer/service to
WebKit.

Or maybe I missed an existing mechanism for passing this information?

+
 Errors
 
     None.
@@ -62,3 +69,4 @@ New State
 Revision History
 
     9/29/2014   Documented the extension.
+    4/12/2016   Added details of OS X RGB workaround.