SRGB_EXT is a valid format of texture in WebGL1.0 and ES2.0 contexts

gpu/command_buffer/service/feature_info.cc

Index: gpu/command_buffer/service/feature_info.cc
diff --git a/gpu/command_buffer/service/feature_info.cc b/gpu/command_buffer/service/feature_info.cc
index 58aa147c2a3e0a9dac15e9063ee17f7580049d46..d66c91e3149dc76e4b4c90bfb8b5927474f32326 100644
--- a/gpu/command_buffer/service/feature_info.cc
+++ b/gpu/command_buffer/service/feature_info.cc
@@ -611,6 +611,7 @@ void FeatureInfo::InitializeFeatures() {
     validators_.render_buffer_format.AddValue(GL_SRGB8_ALPHA8_EXT);
     validators_.frame_buffer_parameter.AddValue(
         GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT);
+    validators_.texture_unsized_internal_format.AddValue(GL_SRGB_EXT);

[Ken Russell (switch to Gerrit), 2016/04/24 15:57:22]

One point. This should only be added for ES 2.0 + the EXT_srgb extension. If the
context is for ES 3.0 / WebGL 2.0, GL_SRGB (which was promoted to core in ES
3.0) is not a valid internal format. Only the sized internal formats GL_SRGB8
and GL_SRGB8_ALPHA8 are valid. Can you please figure out how to add this
constraint? Can you also please extend the WebGL 2.0 conformance tests to make
sure that GL_SRGB is tested as an invalid internal format, if it isn't being
already? Thanks.

[Zhenyao Mo, 2016/04/25 18:00:00]

Right.  This is an issue existing before this CL. We should only expose   this
extension if the context_type_ is WEBGL1 or ES2.

Then on ES3 and Desktop, in Tex{Sub}Image handling, we need to map SRGB and
SRGB_ALPHA to SRGB8 and SRGB8_ALPHA8.

     validators_.texture_unsized_internal_format.AddValue(GL_SRGB_ALPHA_EXT);
   }