Efficiently handle image layer scaling

cc/picture_image_layer_impl.cc

+// 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.
+
+#include "cc/picture_image_layer_impl.h"
+
+#include "cc/debug_colors.h"
+#include "cc/layer_tree_impl.h"
+
+namespace cc {
+
+PictureImageLayerImpl::PictureImageLayerImpl(LayerTreeImpl* treeImpl, int id)
+    : PictureLayerImpl(treeImpl, id) {
+}
+
+PictureImageLayerImpl::~PictureImageLayerImpl() {
+}
+
+const char* PictureImageLayerImpl::layerTypeAsString() const {
+  return "PictureImageLayer";
+}
+
+scoped_ptr<LayerImpl> PictureImageLayerImpl::createLayerImpl(
+    LayerTreeImpl* treeImpl) {
+  return PictureImageLayerImpl::create(treeImpl, id()).PassAs<LayerImpl>();
+}
+
+void PictureImageLayerImpl::getDebugBorderProperties(
+    SkColor* color, float* width) const {
+  *color = DebugColors::ImageLayerBorderColor();
+  *width = DebugColors::ImageLayerBorderWidth(layerTreeImpl());
+}
+
+void PictureImageLayerImpl::CalculateRasterContentsScale(
+    bool animating_transform_to_screen,
+    float* raster_contents_scale,
+    float* low_res_raster_contents_scale) {
+  // Don't scale images during rastering to ensure image quality, save memory
+  // and avoid frequent re-rastering on change of scale.
+  if (ideal_contents_scale_ >

[enne (OOO), 2013/02/22 00:10:49]

I don't understand this math.  If the ideal contents scale is less than minimum
contents scale, then you should not use it for either raster or low_res_raster. 
It's a minimum.

It seems like raster_contents_scale should be ideal_contents_scale clamped
between the minimum and 1.

[Xianzhu, 2013/02/22 00:53:30]

Actually I meant 'ideal_contents_scale_ != minimumContentsScale', i.e. unless
the original bounds is too small (when ideal_contents_scale_ is minimum or is
clamped to minimum), we use the fixed raster_contents_scale=1.

Using ideal_contents_scale_ as raster_contents_scale when it<1 will cause
low-quality image because of the imperfect scaling method in Skia (bug 174628).
In addition as we don't support non-uniform x/y contents scale, rastering will
cause another loss of image quality. Keeping contentsScale=1 will keep all
original information in images, then gpu will do better scaling.

In addition, some page may use a timer to animate the scaling of image which
would be still slow if the scale<1 and we change tiling every time the scale
changes.

If we don't have low-quality image issue, perhaps we can snap the scale to
several predefined levels, e.g. 1, 1/4, 1/16, etc.

[enne (OOO), 2013/02/22 01:18:18]

Ok.  Maybe there's more work to be done here before we can have low-res images. 
In that case, shouldn't the math just be:

*raster_contents_scale =
std::max(layerTreeImpl()->settings().minimumContentsScale(), 1.f);

(In practice the minimum won't ever be more than 1, but might as well take it
into account.)

[Xianzhu, 2013/02/22 23:24:38]

Added std::max in the 'if' block, but still kept the else block for very small
contents scale case.

+      layerTreeImpl()->settings().minimumContentsScale) {
+    *raster_contents_scale = 1.f;
+  }else {
+    // ... except that the contents scale is very small, to save memory.
+    *raster_contents_scale = ideal_contents_scale_;
+  }
+
+  // We don't need low res tiles.
+  *low_res_raster_contents_scale = *raster_contents_scale;
+}
+
+}  // namespace cc