Implement on demand quad rasterization for PicturePiles.

cc/picture_draw_quad.h

Index: cc/picture_draw_quad.h
diff --git a/cc/picture_draw_quad.h b/cc/picture_draw_quad.h
new file mode 100644
index 0000000000000000000000000000000000000000..1f5d724e06da035847c72f9a65694ef4bd838401
--- /dev/null
+++ b/cc/picture_draw_quad.h
@@ -0,0 +1,65 @@
+// Copyright 2013 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_PICTURE_DRAW_QUAD_H_
+#define CC_PICTURE_DRAW_QUAD_H_
+
+#include "base/memory/ref_counted.h"
+#include "base/memory/scoped_ptr.h"
+#include "cc/cc_export.h"
+#include "cc/picture_pile_impl.h"
+#include "cc/tile_draw_quad.h"
+#include "ui/gfx/rect.h"
+#include "ui/gfx/rect_f.h"
+#include "ui/gfx/size.h"
+
+namespace cc {
+
+// Used for on-demand tile rasterization.
+class CC_EXPORT PictureDrawQuad : public TileDrawQuad {

[danakj, 2013/03/14 18:00:56]

These are meant to be simple struct-like things for purpose of IPC, and multiple
levels of polymorphism makes that more difficult. For instance now
PictureDrawQuad has a resource_id that is not used.

I think I'd like this more if PictureDrawQuad didn't need to inherit from
TileDrawQuad. I know you use DrawTileQuad() in GLRenderer, but you could solve
that by making a templated method in GLRenderer that both DrawTileQuad and
DrawPictureQuad called, and it would use the various identical fields off them,
and take as input parameters anything that differed between the two. What would
you think of that approach?

[Leandro Graciá Gil, 2013/03/19 17:30:07]

I'm trying enne's suggestion of a base class while keeping the DrawQuads as
struct-like as possible. If you still think this is not good enough I can try
with your template suggestion.

+ public:
+  static scoped_ptr<PictureDrawQuad> Create();
+
+  void SetNew(const SharedQuadState* shared_quad_state,
+              const gfx::Rect& rect,
+              const gfx::Rect& opaque_rect,
+              const gfx::RectF& tex_coord_rect,
+              const gfx::Size& texture_size,
+              bool swizzle_contents,
+              const gfx::Rect& content_rect,
+              float contents_scale,
+              scoped_refptr<PicturePileImpl> picture_pile);

[danakj, 2013/03/14 18:00:56]

What is the story for serializing these to the browser compositor for ubercomp?

Are we just going to stop using this in M28? Are we going to make
PicturePileImpl serializable securely? What's the plan going forward?

+
+  void SetAll(const SharedQuadState* shared_quad_state,
+              const gfx::Rect& rect,
+              const gfx::Rect& opaque_rect,
+              const gfx::Rect& visible_rect,
+              bool needs_blending,
+              const gfx::RectF& tex_coord_rect,
+              const gfx::Size& texture_size,
+              bool swizzle_contents,
+              const gfx::Rect& content_rect,
+              float contents_scale,
+              scoped_refptr<PicturePileImpl> picture_pile);
+
+  gfx::Rect content_rect;
+  float contents_scale;
+  scoped_refptr<PicturePileImpl> picture_pile;
+
+  virtual bool IsPictureQuad() const OVERRIDE;
+
+  virtual void IterateResources(const ResourceIteratorCallback& callback)
+      OVERRIDE;
+
+  static const PictureDrawQuad* MaterialCast(const DrawQuad*);
+
+ private:
+  virtual DrawQuad::Material material() const OVERRIDE;
+
+  PictureDrawQuad();
+};
+
+}
+
+#endif  // CC_PICTURE_DRAW_QUAD_H_