cc: Do not create separate tilings for almost equal scale factors.

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 30 matching lines @@
 
 // Even for really wide viewports, at some point GPU raster should use
 // less than 4 tiles to fill the viewport. This is set to 256 as a
 // sane minimum for now, but we might want to tune this for low-end.
 const int kMinHeightForGpuRasteredTile = 256;
 
 // When making odd-sized tiles, round them up to increase the chances
 // of using the same tile size.
 const int kTileRoundUp = 64;
 
+// The precision value for rounding floating points values of scale factors.
+// With this scale factors will be having 3 digits fractional part, which will
+// make almost equal (having smaller difference by some magnitude of floating
+// point epsilon) scale factors to be considered as same.
+const int kScalePrecision = 4;
+
 }  // namespace
 
 namespace cc {
 
 PictureLayerImpl::PictureLayerImpl(
     LayerTreeImpl* tree_impl,
     int id,
     bool is_mask,
     scoped_refptr<SyncedScrollOffset> scroll_offset)
     : LayerImpl(tree_impl, id, scroll_offset),
@@ skipping 874 matching lines @@
 }
 
 void PictureLayerImpl::RecalculateRasterScales() {
   float old_raster_contents_scale = raster_contents_scale_;
   float old_raster_page_scale = raster_page_scale_;
   float old_raster_source_scale = raster_source_scale_;
 
   raster_device_scale_ = ideal_device_scale_;
   raster_page_scale_ = ideal_page_scale_;
   raster_source_scale_ = ideal_source_scale_;
-  raster_contents_scale_ = ideal_contents_scale_;
+  // Get fixed precision scale to avoid creating extra tilings for scales
+  // which are almost equal.
+  raster_contents_scale_ =
+      MathUtil::RoundToFixedPrecision(ideal_contents_scale_, kScalePrecision);

[vmpstr, 2015/10/19 18:58:38]

My understanding is that with this, something like 1.004 would become 1.0,
right? (or maybe 1.0004 becomes 1.0). In either case, wouldn't this cause
blurriness? Since 1.0 is actually not the ideal scale, but 1.004 is. I'm not
saying the blurriness would be excessive, but it's probably also not too small
(.004 is 1 pixel in every 250, right?)

Can you fake a pinch scale of 1.004 before and after your patch and have two
screenshots to compare? Something with a lot of text probably would show any
artifacts. I don't know if that's easy to do though...

[prashant.n, 2015/10/20 18:45:24]

We set scale precision as 4. This will give 4 digits in fractional part, IMO,
which is sufficient for distinguishing two scales. e.g. 1.1234. The ideal scale
gets used further as raster contents scale. So there would not occur blurriness.
However I'll check contents with two different scales.

[vmpstr, 2015/10/20 18:55:23]

Yeah you're probably right, but I'd still like to see concrete examples (or at
least some verification). Mostly because it's hard to reason about small float
difference when they affect large layers.

 
   // If we're not animating, or leaving an animation, and the
   // ideal_source_scale_ changes, then things are unpredictable, and we fix
   // the raster_source_scale_ in place.
   if (old_raster_source_scale &&
       !draw_properties().screen_space_transform_is_animating &&
       !was_screen_space_transform_animating_ &&
       old_raster_source_scale != ideal_source_scale_)
     raster_source_scale_is_fixed_ = true;
 
@@ skipping 307 matching lines @@
 
 bool PictureLayerImpl::IsOnActiveOrPendingTree() const {
   return !layer_tree_impl()->IsRecycleTree();
 }
 
 bool PictureLayerImpl::HasValidTilePriorities() const {
   return IsOnActiveOrPendingTree() && IsDrawnRenderSurfaceLayerListMember();
 }
 
 }  // namespace cc