Use the solid color detection to create solid layers

cc/layers/picture_layer_impl.cc

Index: cc/layers/picture_layer_impl.cc
diff --git a/cc/layers/picture_layer_impl.cc b/cc/layers/picture_layer_impl.cc
index 43348fa5000e31ca26b34a48665d1d26598b47c6..48b25d51d6f47b6014f84cda8cdaacb1e1272cea 100644
--- a/cc/layers/picture_layer_impl.cc
+++ b/cc/layers/picture_layer_impl.cc
@@ -75,7 +75,9 @@ PictureLayerImpl::PictureLayerImpl(LayerTreeImpl* tree_impl, int id)
       raster_source_scale_is_fixed_(false),
       was_screen_space_transform_animating_(false),
       needs_post_commit_initialization_(true),
-      should_update_tile_priorities_(false) {
+      should_update_tile_priorities_(false),
+      is_solid_color_(false),
+      solid_color_(SK_ColorBLACK) {
   layer_tree_impl()->RegisterPictureLayerImpl(this);
 }
 
@@ -96,6 +98,7 @@ void PictureLayerImpl::PushPropertiesTo(LayerImpl* base_layer) {
   // It's possible this layer was never drawn or updated (e.g. because it was
   // a descendant of an opacity 0 layer).
   DoPostCommitInitializationIfNeeded();
+
   PictureLayerImpl* layer_impl = static_cast<PictureLayerImpl*>(base_layer);
 
   // We have already synced the important bits from the the active layer, and
@@ -117,6 +120,9 @@ void PictureLayerImpl::PushPropertiesTo(LayerImpl* base_layer) {
   layer_impl->SetIsMask(is_mask_);
   layer_impl->pile_ = pile_;
 
+  layer_impl->is_solid_color_ = is_solid_color_;
+  layer_impl->solid_color_ = solid_color_;
+
   // Tilings would be expensive to push, so we swap.
   layer_impl->tilings_.swap(tilings_);
 
@@ -151,6 +157,43 @@ void PictureLayerImpl::AppendQuads(
     RenderPass* render_pass,
     const OcclusionTracker<LayerImpl>& occlusion_tracker,
     AppendQuadsData* append_quads_data) {
+  if (IsSolidColor()) {

[vmpstr, 2014/08/29 06:49:15]

Can you put this code in a helper and do

if (IsSolidColor()) {
  AppendQuadsForSolidColor(...);
  return;
}

[hendrikw, 2014/08/29 14:03:21]

As I mentioned in the post above, I will need to derive PictureLayerImpl from
SolidColorLayer and share that functionality completely.  I didn't have time to
complete this, I wanted to get this cl out quickly since I'm technically on
vacation now.

[vmpstr, 2014/08/29 14:20:45]

Can you have a SolidColorLayerImpl as a member instead? It feels weird deriving
from it.

[enne (OOO), 2014/08/29 16:53:43]

Please, no to either deriving from PictureLayerImpl or having a
SolidColorLayerImpl as a member.

What about making some SolidColorQuadGenerator class that both of them could
use?  It could even just have no members and only static functions that you have
to pass the right things into.

[hendrikw, 2014/09/02 14:19:17]

I already tried that.  It calls AppendDebugBorderQuad, which is a protected
function of LayerImpl.

I can think of several ways around this -- this last one has a helper function
in layerimpl

[vmpstr, 2014/09/02 19:02:25]

I feel that LayerImpl should really move more towards being an interface type of
thing. In that spirit, I think putting more functionality there that is kind of
specific to a couple of implementations is moving in the other direction. 

Feel free to disagree, but I would vote for trying to make a separate helper
class for PictureLayerImpl and SolidColorLayerImpl instead of using LayerImpl
for that purpose.

+    // TODO(hendrikw) code sharing
+    const int tile_size_ = 256;  // this comes from solidcolorlayerimpl

[vmpstr, 2014/08/29 06:49:15]

trailing _ is for member variables. This should be const int kSolidColorTileSize
in the anonymous namespace

[hendrikw, 2014/08/29 14:03:21]

This will go away when I derive from solid color.

[vmpstr, 2014/08/29 14:20:44]

Acknowledged.

+    SharedQuadState* shared_quad_state =
+        render_pass->CreateAndAppendSharedQuadState();
+    PopulateSharedQuadState(shared_quad_state);
+
+    AppendDebugBorderQuad(

[vmpstr, 2014/08/29 06:49:15]

Should each of the solid color quads also have a debug border quad of some other
color?

[hendrikw, 2014/08/29 14:03:21]

This functionality will exist in solid color when I'm done, I don't plan on
changing it, in fact, all of this code should be rewritten, we're not batching
the quads. I'm not convinced that it makes sense to check occlusions and output
rects (on hardware), we probably should just output one rect, but this is out of
scope for this change.

[vmpstr, 2014/08/29 14:20:44]

Acknowledged.

+        render_pass, content_bounds(), shared_quad_state, append_quads_data);
+
+    // We create a series of smaller quads instead of just one large one so that

[enne (OOO), 2014/08/29 16:53:43]

This code is not your fault, but we shouldn't do this anymore.  Occlusion used
to be outside the layer at the quad level and so the solid color layer had to be
split up into small enough quads that some of them could be occluded.

You can now ask the occlusion tracker for the occlusion rect directly, and so
it'd be better to generate the minimal set of rects from that.  Each quad is a
needless draw call, so it'd be better to not have to do this splitting.

If you want to punt to another patch, that's fine, but it'd be a good followup.

[hendrikw, 2014/09/02 14:19:17]

Acknowledged.

+    // the culler can reduce the total pixels drawn.
+    int width = content_bounds().width();
+    int height = content_bounds().height();
+    for (int x = 0; x < width; x += tile_size_) {
+      for (int y = 0; y < height; y += tile_size_) {
+        gfx::Rect quad_rect(x,
+                            y,
+                            std::min(width - x, tile_size_),
+                            std::min(height - y, tile_size_));
+        gfx::Rect visible_quad_rect = occlusion_tracker.UnoccludedContentRect(
+            quad_rect, draw_properties().target_space_transform);
+        if (visible_quad_rect.IsEmpty())
+          continue;
+
+        SolidColorDrawQuad* quad =
+            render_pass->CreateAndAppendDrawQuad<SolidColorDrawQuad>();
+        quad->SetNew(shared_quad_state,
+                     quad_rect,
+                     visible_quad_rect,
+                     solid_color_,
+                     false);
+      }
+    }
+    return;
+  }
+
   DCHECK(!needs_post_commit_initialization_);
 
   float max_contents_scale = MaximumTilingContentsScale();
@@ -584,7 +627,8 @@ skia::RefPtr<SkPicture> PictureLayerImpl::GetPicture() {
 
 scoped_refptr<Tile> PictureLayerImpl::CreateTile(PictureLayerTiling* tiling,
                                                const gfx::Rect& content_rect) {
-  if (!pile_->CanRaster(tiling->contents_scale(), content_rect))
+  if (!pile_->CanRaster(tiling->contents_scale(), content_rect) ||

[vmpstr, 2014/08/29 06:49:15]

Hmm, I was hoping to avoid creating tilings at all for this, since things like
tile priorities updates and whatever else have non-zero cost that is unneeded
for solid color. Is that possible?

[hendrikw, 2014/08/29 14:03:21]

If there are no tiles in the tiling, why would updating tile priorities do
anything?

[vmpstr, 2014/08/29 14:20:45]

If we don't create tilings, then this function should never be called. So you
should DCHECK(!IsSolidColor()) instead then.

+      IsSolidColor())
     return scoped_refptr<Tile>();
 
   // TODO(vmpstr): Revisit this. For now, enabling analysis means that we get as
@@ -1780,4 +1824,10 @@ size_t PictureLayerImpl::LayerEvictionTileIterator::CurrentTilingIndex() const {
   return 0;
 }
 
+void PictureLayerImpl::SetSolidColorState(bool is_solid_color,
+                                          SkColor solid_color) {
+  is_solid_color_ = is_solid_color;
+  solid_color_ = solid_color;
+}
+
 }  // namespace cc