Add support to send optimal format as part of ScheduleOverlayPlane

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 1dec5cf2002c7dfcdf9db9099edbdfd5c3b84b1b..3ecd3f0bd4fee60ffaf039a7f8e5d5d7f9c53a31 100644
--- a/gpu/command_buffer/service/gles2_cmd_decoder.cc
+++ b/gpu/command_buffer/service/gles2_cmd_decoder.cc
@@ -173,6 +173,20 @@ gfx::OverlayTransform GetGFXOverlayTransform(GLenum plane_transform) {
   }
 }
 
+gfx::BufferFormat GetGFXOverlayStorageFormat(GLuint storage_format) {
+  switch (storage_format) {
+    case GL_BGR:
+      return gfx::BufferFormat::BGRX_8888;
+    case GL_BGRA_EXT:
+      return gfx::BufferFormat::BGRA_8888;
+    case GL_RGB_YCBCR_422_CHROMIUM:
+      return gfx::BufferFormat::UYVY_422;
+    default:
+      NOTREACHED();
+      return gfx::BufferFormat::BGRX_8888;
+  }
+}
+
 template <typename MANAGER_TYPE, typename OBJECT_TYPE>
 GLuint GetClientId(const MANAGER_TYPE* manager, const OBJECT_TYPE* object) {
   DCHECK(manager);
@@ -9433,9 +9447,11 @@ error::Error GLES2DecoderImpl::HandleScheduleOverlayPlaneCHROMIUM(
   if (!surface_->ScheduleOverlayPlane(
           c.plane_z_order,
           transform,
+          GetGFXOverlayStorageFormat(c.storage_format),

[piman, 2015/12/11 08:32:25]

When would this be different than the image's BufferFormat?
What happens if they don't match? We can't trust the client.

[kalyank, 2015/12/11 19:22:35]

This might be different in case HardwarePlanes support formats
which can reduce the bandwidth. In ChromeOS case we hardcode these
checks in GbmPixmap 
https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/...

https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/...

We decide if we need to do any format conversions or handle any scaling requests
and do it here. This is wrong as some hardware might not support these
formats or can handle plane scaling (would help reduce bandwidth in upscaling
cases). This information needs to come from HardwareDisplayPlaneManager and will
vary depending on the combination of layers using HardwarePlanes during a page
flip request. The other option would be to query this from PlaneManager while
scheduling the plane, however this would mean having to maintain a cache of
Overlay configurations being in use and making sure it's in sync with the
pending swaps in GLSurfaceOzone.

https://code.google.com/p/chromium/codesearch#chromium/src/ui/ozone/platform/...

           image,
           gfx::Rect(c.bounds_x, c.bounds_y, c.bounds_width, c.bounds_height),
-          gfx::RectF(c.uv_x, c.uv_y, c.uv_width, c.uv_height))) {
+          gfx::RectF(c.uv_x, c.uv_y, c.uv_width, c.uv_height),
+          static_cast<GLboolean>(c.handle_scaling))) {

[piman, 2015/12/11 08:32:25]

Same here, what happens if handle_scaling doesn't match whether
(uv_width,uv_height)*image->GetSize() is equal to (bounds_width,bounds_height)?

     LOCAL_SET_GL_ERROR(GL_INVALID_OPERATION,
                        "glScheduleOverlayPlaneCHROMIUM",
                        "failed to schedule overlay");