cc: Fork OverlayCandidate to CALayerOverlay

cc/output/ca_layer_overlay.h

Index: cc/output/ca_layer_overlay.h
diff --git a/cc/output/ca_layer_overlay.h b/cc/output/ca_layer_overlay.h
new file mode 100644
index 0000000000000000000000000000000000000000..fd7d68f173c21a3a076775ee70d674d91d0e61bf
--- /dev/null
+++ b/cc/output/ca_layer_overlay.h
@@ -0,0 +1,49 @@
+// Copyright 2015 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 CC_OUTPUT_CA_LAYER_OVERLAY_H_
+#define CC_OUTPUT_CA_LAYER_OVERLAY_H_
+
+#include "cc/quads/render_pass.h"
+#include "third_party/skia/include/core/SkColor.h"
+#include "third_party/skia/include/utils/SkMatrix44.h"
+#include "ui/gfx/geometry/rect_f.h"
+
+namespace cc {
+
+class DrawQuad;
+class ResourceProvider;
+
+class CC_EXPORT CALayerOverlay {
+ public:
+  CALayerOverlay();
+  ~CALayerOverlay();
+
+  // Texture that corresponds to an IOSurface to set as the content of the
+  // CALayer. If this is 0 then the CALayer is a solid color.
+  unsigned contents_resource_id;

[alexst (slow to review), 2015/11/12 14:36:18]

I wonder if we could fork things a bit further downstream and refactor the code
a bit.

I made the original overlay candidate struct intentionally small and limited in
scope with the expectation that we could grow it as needed by all platforms.
Things like background color and matrix transform are not out of place there, it
would be nice to branch into platform code as late as possible.

It's not a major objection, I would be fine with current code, but I can't shake
the feeling it could stay a bit more generic in earlier stages.

[ccameron, 2015/11/12 17:31:47]

I was going in this direction at first, but back in
https://codereview.chromium.org/1394403002/, we decided to do a fork at around
this level.

The CALayer representation of an overlay is very different from the hardware
overlay planes (CALayers don't even have pixel rects -- they have floating-point
size and then a 3D transform matrix), so merging the two would be fairly
difficult. I also wanted to reuse OverlayCandidate::FromDrawQuad, but there
ended up being very little to share.

That said, when we add Wayland and/or DirectCompositing support, we may finally
see a way to merge these.

+  // The contents rect property for the CALayer.
+  gfx::RectF contents_rect;
+  // The opacity property for the CAayer.
+  float opacity;
+  // The background color property for the CALayer.
+  SkColor background_color;
+  // The bounds for the CALayer in pixels.
+  gfx::SizeF bounds_size;
+  // The transform to apply to the CALayer.
+  SkMatrix44 transform;
+};
+
+typedef std::vector<CALayerOverlay> CALayerOverlayList;
+
+// Returns true if all quads in the root render pass have been replaced by
+// CALayerOverlays.
+bool ProcessForCALayerOverlays(ResourceProvider* resource_provider,
+                               const gfx::RectF& display_rect,
+                               const QuadList& quad_list,
+                               CALayerOverlayList* ca_layer_overlays);
+
+}  // namespace cc
+
+#endif  // CC_OUTPUT_CA_LAYER_OVERLAY_H_