Add command buffer support for GL_RGB CHROMIUM image emulation.

ui/gl/gl_image.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef UI_GL_GL_IMAGE_H_
 #define UI_GL_GL_IMAGE_H_
 
 #include <stdint.h>
 
 #include <string>
@@ skipping 56 matching lines @@
                                     gfx::OverlayTransform transform,
                                     const gfx::Rect& bounds_rect,
                                     const gfx::RectF& crop_rect) = 0;
 
   // Dumps information about the memory backing the GLImage to a dump named
   // |dump_name|.
   virtual void OnMemoryDump(base::trace_event::ProcessMemoryDump* pmd,
                             uint64_t process_tracing_id,
                             const std::string& dump_name) = 0;
 
+  // If this returns true, then the command buffer client has requested a
+  // CHROMIUM image with internalformat GL_RGB, but the platform only supports
+  // GL_RGBA. The client is responsible for implementing appropriate
+  // workarounds. The only support that the command buffer provides is format
+  // validation during calls to copyTexImage2D and copySubTexImage2D.
+  virtual bool EmulatingRGB() const;

[reveman, 2016/04/07 13:00:56]

Maybe I'm just being defensive of the code I've designed, written and maintains
but I'd really like to see this be restricted to the command buffer
client/service somehow. This lower level ui/gl code should not be aware of
concepts such as command buffer client and command buffer service.

Can we instead just hard code this in the command buffer service as all glimages
with RGB format on MacOS being emulated and not touch the GLImage interface?

[Ken Russell (switch to Gerrit), 2016/04/07 21:41:14]

The comments don't need to reference the command buffer, but one way or another,
it seems that GLImage is going to have to know that it was allocated with type
GL_RGB and actually allocated a GL_RGBA type image internally. It seems
inappropriate to keep this knowledge entirely outside the GLImage class, when
the contract explicitly states that GL_RGB type images are supported, but this
is infeasible on the Mac platform.

I don't have a strong opinion on how this is implemented but it seems
appropriate to me that one of the following be done:

1) there be some kind of query on GLImage either for the requested and actually
allocated formats
2) there be some knowledge that the GLImage was allocated with GL_RGB format,
but GL_RGBA was actually allocated

David, I hope you'll not push back on recording this information in the GLImage
instance, since it looks like it would otherwise mean maintaining an entirely
separate hash table. Looking again at Erik's changes to texture_manager.cc, it
seems that the best (most localized, etc.) place to record this information is
on the GLImage instance itself.

[reveman, 2016/04/08 15:59:38]

Why do we need to record it at all? Isn't EmulatingRGB going to be true for all
GLImage instances on Mac where internalformat is RGB?

+
  protected:
   virtual ~GLImage() {}
 
  private:
   friend class base::RefCounted<GLImage>;
 
   DISALLOW_COPY_AND_ASSIGN(GLImage);
 };
 
 }  // namespace gl
 
 #endif  // UI_GL_GL_IMAGE_H_