cc: Re-use transforms from transform nodes when computing visible rects

cc: Re-use transforms from transform nodes when computing visible rects

This makes CalculateVisibleRects try to re-use the to_target and
from_target transforms stored in transform nodes whenever it needs to
compute a transform. Since these baked transforms incorporate the
target's sublayer scale, the fallback path now also includes sublayer
scale for consistency.

Testing locally on a z620, this improves property tree computation time
by 25% on rAF-driven poster circle.

BUG=474725
Committed: https://crrev.com/3ae2b258d39e00f11212167be326b5a6a78d3793
Cr-Commit-Position: refs/heads/master@{#324671}

[ajuma, 2015-04-07 20:43:47]

ajuma@chromium.org changed reviewers:
+ vollick@chromium.org

[Ian Vollick, 2015-04-07 21:10:05]

lgtm!

https://codereview.chromium.org/1060413002/diff/20001/cc/trees/draw_property_...
File cc/trees/draw_property_utils.cc (right):

https://codereview.chromium.org/1060413002/diff/20001/cc/trees/draw_property_...
cc/trees/draw_property_utils.cc:62: if (target_node->data.needs_sublayer_scale)
{
aside: it would be really nice if we could tell ComputeTransform to include the
sublayer scale and not repeat this sort of code everywhere.

[ajuma, 2015-04-07 21:19:30]

https://codereview.chromium.org/1060413002/diff/20001/cc/trees/draw_property_...
File cc/trees/draw_property_utils.cc (right):

https://codereview.chromium.org/1060413002/diff/20001/cc/trees/draw_property_...
cc/trees/draw_property_utils.cc:62: if (target_node->data.needs_sublayer_scale)
{
On 2015/04/07 21:10:05, vollick wrote:
> aside: it would be really nice if we could tell ComputeTransform to include
the
> sublayer scale and not repeat this sort of code everywhere.

Good idea, I'll do that in a follow-up.

[ajuma, 2015-04-07 21:19:34]

The CQ bit was checked by ajuma@chromium.org

[commit-bot: I haz the power, 2015-04-07 21:20:24]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1060413002/20001

[commit-bot: I haz the power, 2015-04-07 21:24:24]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-04-07 21:25:14]

Patchset 2 (id:??) landed as
https://crrev.com/992c398b2fb0e7ab9c7ba58a8eb36787e03962e4
Cr-Commit-Position: refs/heads/master@{#324122}

[cbiesinger, 2015-04-08 17:46:14]

Could this have caused layout test failures on Windows XP?

https://build.chromium.org/p/chromium.webkit/builders/WebKit%20XP
https://storage.googleapis.com/chromium-layout-test-archives/WebKit_XP/18254/...

[Ian Vollick, 2015-04-08 17:52:42]

On 2015/04/08 17:46:14, cbiesinger wrote:
> Could this have caused layout test failures on Windows XP?
> 
> https://build.chromium.org/p/chromium.webkit/builders/WebKit%20XP
>
https://storage.googleapis.com/chromium-layout-test-archives/WebKit_XP/18254/...

No, the only way that property trees could cause failures is by inducing crashes
when the corresponding CHECKs fail.

[ajuma, 2015-04-08 17:53:01]

On 2015/04/08 17:46:14, cbiesinger wrote:
> Could this have caused layout test failures on Windows XP?
> 
> https://build.chromium.org/p/chromium.webkit/builders/WebKit%20XP
>
https://storage.googleapis.com/chromium-layout-test-archives/WebKit_XP/18254/...

No, this could not have caused those failures. The transforms computed by
property trees aren't plumbed back to Blink or used for rendering. (For now,
they are only compared to the transforms computed by CalcDrawProps.)

[ajuma, 2015-04-08 21:49:36]

A revert of this CL (patchset #2 id:20001) has been created in
https://codereview.chromium.org/1077433003/ by ajuma@chromium.org.

The reason for reverting is: Causes css3/filters/effect-reference-hidpi-hw.html
to have an incorrect visible rect..

[ajuma, 2015-04-10 17:05:09]

PTAL. I've fixed the incorrect visible rect (I was calling Scale when I should
have called postScale, and vice-versa), added methods to TransformTree for
computing transforms with sublayer scale included, and added a test.

I re-measured performance locally. This is still a big win on poster circle (a
25% improvement), but the improvement on Gmail is now within the noise (roughly
1.5%).

[Ian Vollick, 2015-04-10 17:10:40]

lgtm (great test!)

https://codereview.chromium.org/1060413002/diff/140001/cc/trees/property_tree.cc
File cc/trees/property_tree.cc (right):

https://codereview.chromium.org/1060413002/diff/140001/cc/trees/property_tree...
cc/trees/property_tree.cc:80: gfx::Transform* transform) const {
Thank you very much for adding these. Would it make sense to try and use them in
Layer::draw_transform_from.. (in another cl)?

[ajuma, 2015-04-10 17:19:49]

https://codereview.chromium.org/1060413002/diff/140001/cc/trees/property_tree.cc
File cc/trees/property_tree.cc (right):

https://codereview.chromium.org/1060413002/diff/140001/cc/trees/property_tree...
cc/trees/property_tree.cc:80: gfx::Transform* transform) const {
On 2015/04/10 17:10:39, vollick wrote:
> Thank you very much for adding these. Would it make sense to try and use them
in
> Layer::draw_transform_from.. (in another cl)?

It looks like that method only applies sublayer scale when it isn't
computing/reading any other transform, so these might not be a great fit over
there.

[ajuma, 2015-04-10 17:22:07]

The CQ bit was checked by ajuma@chromium.org

[commit-bot: I haz the power, 2015-04-10 17:22:45]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1060413002/140001

[commit-bot: I haz the power, 2015-04-10 18:30:30]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2015-04-10 18:31:45]

Patchset 8 (id:??) landed as
https://crrev.com/3ae2b258d39e00f11212167be326b5a6a78d3793
Cr-Commit-Position: refs/heads/master@{#324671}