cc: Force an update on tile size after viewport resize

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 93d658159516549e0164c2e55790fea982a05370..08e0a6ee870539bb0ed883a6bd33d9998b7f3f27 100644
--- a/cc/layers/picture_layer_impl.cc
+++ b/cc/layers/picture_layer_impl.cc
@@ -390,6 +390,19 @@ bool PictureLayerImpl::UpdateTiles(bool resourceless_software_draw) {
   DCHECK_EQ(1.f, contents_scale_x());
   DCHECK_EQ(1.f, contents_scale_y());
 
+  // GPU rasterization can cause a tile size change when the viewport changes.
+  // Ensure that the tiling's texture sizes are correct after a viewport resize
+  // by tracking the last viewport rect and updating the current raster source,
+  // which will in turn update the tiling's texture size.
+  if (!last_viewport_size_.IsEmpty() &&

[danakj, 2015/03/18 21:46:14]

This looks like it should be below the !CanHaveTilings() early out.

[hendrikw, 2015/03/18 22:06:31]

Yeah, you're right.

+      last_viewport_size_ != layer_tree_impl()->device_viewport_size() &&
+      layer_tree_impl()->IsPendingTree()) {
+    tilings_->UpdateTilingsToCurrentRasterSource(

[vmpstr, 2015/03/18 21:36:39]

In "typical" situations where the device viewport changes and we get like layout
or something, this function would already be called. What are the implications
of calling it for the second time?

It seems that at the very least it's would invalidate again. Is it just going to
be a performance hit? In that case, I'm not sure that taking a performance hit
in a typical situation in order to fix a rare situation is... good? 

I might just be making noise though, since I don't think UpdateTiles is a
many-times-a-frame type of an operation.

[danakj, 2015/03/18 21:46:14]

What if there's no pending tree (commit to active, so this is the active tree),
but the viewport changed. We won't DCHECK cuz there's no sync, but we'll have
tiles of the wrong size still?

For that reason I kinda wonder if this shouldn't be handled in PictureLayer
instead, by it making sure to push a new RasterSource if the viewport size
changed? Or something else on the main thread side? That would address your
concern about putting this in UpdateTiles too? I'm not sure.

[hendrikw, 2015/03/18 22:06:31]

Yeah, my first change (https://codereview.chromium.org/1018463005/) would
trigger the push when we get a viewport size change, the SetNeedsPushProperties
is what normally causes the tiling texture size to be recalculated, but it
doesn't work for the layers sitting out of the viewport, earlies out before the
needs push.

Enne thinks the other approach is more work than what's needed, and too
indirect, and might possibly be optimized out (although hopefully my unit test
would catch that).

I think I prefer the other approach.

+        raster_source_, nullptr, invalidation_, MinimumContentsScale(),
+        MaximumContentsScale());
+  }
+  last_viewport_size_ = layer_tree_impl()->device_viewport_size();
+
   if (!resourceless_software_draw) {
     visible_rect_for_tile_priority_ = visible_content_rect();
   }