* One proposal:

https://docs.google.com/document/d/1P4I2MxA0E1eyf4ihULaktIk4UdOtIDLWg9Tp2Y7g_-M/edit#

This is equivalent to a feature on CALayer for iOS.


* Another (via danakj & others, starting at comment 41 here: https://bugs.chromium.org/p/chromium/issues/detail?id=600482#c41):

- Use will-change: transform to indicate that the developer intends to animate transform, and therefore we
 should not re-raster on scale change. Removing will-change: transform will trigger a raster (as well as all
subsequent frames that change scale, until will-change: transform is re-added).

Another example here: https://bugs.chromium.org/p/chromium/issues/detail?id=607517

 Issue 607517  has been merged into this issue.

 Issue 609229  has been merged into this issue.

Plan is to implement and launch option 1, as outlined in this document:

https://docs.google.com/document/d/1CsDfsMxZaM094VhTDrHXF86_rmFnpjM8xL3iEh7HWgg/edit

 Issue 556533  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/edd476edadbe9b9316f3527b0692836ced4230ce

commit edd476edadbe9b9316f3527b0692836ced4230ce
Author: vmpstr <vmpstr@chromium.org>
Date: Wed Jun 22 23:13:37 2016

cc: Remove fixed raster scale, stop rasterizing with will-change.

This patch replaces the current behavior of blocking all new scales
once the ideal scale changes once. The new behavior looks at a
will-change transform property:

- If will-change is present, we don't reraster or choose a new scale.
- If will-change is absent, we keep rerastering at a new scale.

R=danakj@chromium.org, chrishtr@chromium.org
BUG= 600867 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/2068413002
Cr-Commit-Position: refs/heads/master@{#401450}

[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/blimp/client/feature/compositor/blimp_compositor.h
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/layers/picture_layer_impl.cc
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/layers/picture_layer_impl.h
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/layers/picture_layer_impl_unittest.cc
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/proto/begin_main_frame_and_commit_state.proto
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/test/fake_layer_tree_host_client.h
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/test/layer_tree_test.cc
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/trees/layer_tree_host.cc
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/trees/layer_tree_host.h
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/trees/layer_tree_host_client.h
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/trees/layer_tree_host_impl.cc
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/trees/layer_tree_host_impl.h
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/trees/layer_tree_host_unittest_remote_server.cc
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/trees/layer_tree_impl.cc
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/trees/layer_tree_impl.h
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/trees/proxy_common.cc
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/trees/proxy_common.h
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/trees/proxy_impl.cc
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/trees/proxy_main.cc
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/cc/trees/single_thread_proxy.cc
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/content/browser/renderer_host/compositor_impl_android.h
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/content/renderer/gpu/render_widget_compositor.cc
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/content/renderer/gpu/render_widget_compositor.h
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/content/renderer/gpu/render_widget_compositor_delegate.h
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/content/renderer/gpu/render_widget_compositor_unittest.cc
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/content/renderer/render_widget.cc
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/content/renderer/render_widget.h
[delete] https://crrev.com/1ebd04a612726d97423917c58ec209c64e0e5304/third_party/WebKit/LayoutTests/compositing/fixed-raster-scale-use-counts-expected.txt
[delete] https://crrev.com/1ebd04a612726d97423917c58ec209c64e0e5304/third_party/WebKit/LayoutTests/compositing/fixed-raster-scale-use-counts.html
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/third_party/WebKit/Source/core/frame/UseCounter.h
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/third_party/WebKit/Source/platform/testing/WebLayerTreeViewImplForTesting.h
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/third_party/WebKit/Source/web/WebViewImpl.cpp
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/third_party/WebKit/Source/web/WebViewImpl.h
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/third_party/WebKit/public/web/WebWidget.h
[modify] https://crrev.com/edd476edadbe9b9316f3527b0692836ced4230ce/ui/compositor/compositor.h

Is there some follow up work to allow devs to specify the actual scale independent from the transform they are using (aka rasterScale property or some such)?

I filed https://github.com/w3c/csswg-drafts/issues/236. Pending what happens with
that bug, we can file a new one here for any implementation.