Update GL_IMPLEMENTATION_COLOR_READ_FORMAT for BGRA

gpu/command_buffer/service/gles2_cmd_decoder.cc

Index: gpu/command_buffer/service/gles2_cmd_decoder.cc
diff --git a/gpu/command_buffer/service/gles2_cmd_decoder.cc b/gpu/command_buffer/service/gles2_cmd_decoder.cc
index a3ad42338965a9e9f7e5c85fb6e133d83079545d..b0442e124dfb08cc5c14824c9e725b969e75e099 100644
--- a/gpu/command_buffer/service/gles2_cmd_decoder.cc
+++ b/gpu/command_buffer/service/gles2_cmd_decoder.cc
@@ -5114,7 +5114,9 @@ bool GLES2DecoderImpl::GetHelper(
               return true;
           }
           *params = GLES2Util::GetGLReadPixelsImplementationFormat(
-              GetBoundReadFrameBufferInternalFormat());
+              GetBoundReadFrameBufferInternalFormat(),
+              GetBoundReadFrameBufferTextureType(),
+              feature_info_->feature_flags().ext_read_format_bgra);

[no sievers, 2016/03/08 00:26:28]

Don't we strictly speaking also have to check whether we support GL_EXT_bgra?

Sure we don't want to be noncompliant wrt the client by returning BGRA here
without having advertised GL_EXT_read_format_bgra, but isn't it a bit fragile
and relying on this being implied here (because we are in a desktop-only path
here and because of the logic in feature_info.cc).

[no sievers, 2016/03/08 00:28:44]

And also note that checking the internal format is not good enough because you
can have GL_EXT_texture_format_BGRA8888 but not support the same host memory
format.

[piman, 2016/03/08 00:48:07]

On desktop GL, the format/type is orthogonal to the internal format in the sense
that you can mix & match BGRA vs RGBA, and the driver is responsible for the
translation (for both read and write). We only get here if we support full
GL_EXT_bgra, I think?

         }
         return true;
       case GL_IMPLEMENTATION_COLOR_READ_TYPE: