cc: Force an update on tile size after viewport resize

cc/layers/picture_layer_impl.cc

 // Copyright 2012 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.
 
 #include "cc/layers/picture_layer_impl.h"
 
 #include <algorithm>
 #include <cmath>
 #include <limits>
 #include <set>
@@ skipping 372 matching lines @@
   // that this is at the expense of doing cause more frequent re-painting. A
   // better scheme would be to maintain a tighter visible_content_rect for the
   // finer tilings.
   CleanUpTilingsOnActiveLayer(last_append_quads_tilings_);
 }
 
 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();
   }
 
   if (!CanHaveTilings()) {
     ideal_page_scale_ = 0.f;
     ideal_device_scale_ = 0.f;
     ideal_contents_scale_ = 0.f;
     ideal_source_scale_ = 0.f;
     SanityCheckTilingState();
@@ skipping 825 matching lines @@
 
 bool PictureLayerImpl::IsOnActiveOrPendingTree() const {
   return !layer_tree_impl()->IsRecycleTree();
 }
 
 bool PictureLayerImpl::HasValidTilePriorities() const {
   return IsOnActiveOrPendingTree() && IsDrawnRenderSurfaceLayerListMember();
 }
 
 }  // namespace cc