Tested on latest Stable #64.0.3282.137 using Samsung S6 and Samsung S7 and observed the below observations by following steps below:

1. Connected mobile device to desktop version of Chrome.
2. Navigate to More Tools >> Remote Devices 
3. From the navigated URL provided in example, click on "INSPECT" button.
4. Check "FPS Meter".
5. Scroll across the page on the mobile device.

Observed that:
1. Frame rate is between ~12 to ~20 on Samsung S6 Android 6.0.1
2. Frame rate is between ~45 to ~50 on Samsung J7 Android 7.0.0

manjian2006@ - Could you please confirm what is the actual expected behavior to differentiate good and behavior. Could you please let us know in detail or could you please share screen cast.

Attached screen cast of our observations.

Thanks in advance!

Deleted: 818129.mp4 1.9 MB

	818129.mp4 1.9 MB View Download

Two new video attached. The first one is the original chrome. As you can see, even with the content unchanged, the FPS meter is running. But the second one which fixes this problem, the FPS meter barely moves.

Deleted: power_consuming.mp4 610 KB

	power_consuming.mp4 610 KB View Download

Deleted: expecting.mp4 1.7 MB

	expecting.mp4 1.7 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

manjian2006@ -- As per my understanding, second one is after updating the patch file "damage_tracker.patch" provided by you in the original comment.

Could you also please let us know in detail how is the patch updated to Chrome to get the issue fixed. Can this issue be considered as Feature Request.

Thanks!

Yes.The second video is the after patch result.
patch -p 1 < damage_tracker.patch

In the root of the source tree will apply the patch.

2018年3月7日 下午9:52，"pnanguno… via monorail" <
monorail+v2.787253306@chromium.org>写道：

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Requesting Internals>Compositing dev team to take a look into this issue.

Thanks!

ajuma@, this seems like it may be an issue relating to CC DamageTracker, can you take a look?

Thanks for the bug report and for writing a patch.

Looking at the patch from comment 0, intersecting the new layer rect with the surface content rect seems like a good idea. But old_rect_in_target_space has to be added to the damage regardless, since this has to do with where the layer previously was on screen (so is unrelated to how the layer currently intersects the target rect).

Bug reporter, would you be interested in posting your patch for review (at chromium-review.googlesource.com)? You'll need to add a unit test and possibly update expectations of existing tests. (Tests are in damage_tracker_unittest.cc; you can run them by building/running cc_unittests.) Happy to help with questions; feel free to ask them here or on a code review.

I agree with you about the old_rect_in_target_space. There must be cases it impacts the render surface. So here is two way to make it right.
1:
Two control flow like patch 1. One more 'if' to measure the impact.
Merit: Precise.
Demerit: One more burden for the branch predictor.

2:
Union first like patch 2. The merit and the demerit is the opposite of the first solution.

Please review them and decide which one is better.

Deleted: both_intersect.patch 1.2 KB

both_intersect.patch 1.2 KB Download

Deleted: union.patch 1.1 KB

union.patch 1.1 KB Download

old_rect_in_target_space shouldn't be intersected with the surface content rect. Say the layer is being moved from the top-left of the screen to the bottom-right. The top-left of the screen (i.e., the old_rect_in_target_space) is damaged even if the surface content rect no longer includes that area, since we need to redraw that part of the screen.

It's much easier to review patches on the code review site though :) That also lets us run try jobs to see if your patch passes tests (and you should also run cc_unittests locally).

Please upload a patch using the command "git cl upload". Also see http://dev.chromium.org/developers/contributing-code

I have upload the patch for review
https://chromium-review.googlesource.com/c/chromium/src/+/958300

Thanks for uploading and sorry for not noticing it! The code review site doesn't send email to reviewers until you click the Start Review button (but this is very non-obvious).

 manjian2006@, are you still planning on working on this?

Yes. But I have no idea what is the next step. The discussion seems being
interrupted.


aj… via monorail <monorail+v2.1702376237@chromium.org> 于 2018年4月23日周一
下午11:12写道：

The next step would be to try out the suggestion in weiliangc@'s review comment on your CL ("Could we use drawable_content_rect instead?"). That is, replace the call to layer->GetEnclosingRectInTargetSpace() with layer->drawable_content_rect() and remove the other changes. The reason this should work is that the render surface content rect is (essentially) formed by taking the union of the drawable content rects of the layers that contribute to it, so by definition the layer's drawable_content_rect will be within the surface content rect.

Also, please click "Start review" on your CL so that comments posted there will trigger email to reviewers.

My child just get birth. So there would be some delay

2018-04-24 9:57 GMT+08:00 aj… via monorail
<monorail+v2.1702376237@chromium.org>:

I am back, let's proceed.

This demo minimize the case the problematic page shown.
With the E_loading commented out, the damage tracker do its job well. And HasDamage method uses  
bool root_surface_has_visible_damage =
      root_surface->GetDamageRect().Intersects(root_surface->content_rect());
figures out the damage rect is not inside root surface.

With the E_loading enabled, there will be two layer contributing to the damage rect. One at the bottom, which is the J_loading class. The other at the far left side as the "fixed" class indicates.

And they result in a huge damage rect.

That's why I exclude all the layers which does not intersect with the content rect.  
 

Deleted: exploit.html 1.8 KB

exploit.html 1.8 KB View Download