We're not routing the VSync parameters to the ui::Compositor, so the fact that any animation doesn't drop-or-double frames is basically coincidence (!)

This also invalidates all of my previous power benchmarks.

#2: By "invalidates" you mean "makes such a large difference that the previous results will be incomparable", or do you mean "the measurements were not correct because of a bug in measurement"?

Either way, exciting!

"invalidates" means "this bug probably changes the results substantially, so we need to re-do the measurements"

I have a patch out for this, but I'm still getting very different MacViews v Cocoa power:

The IQR (variance) has gone down, but the GPU vs CPU power is wildly different. They "mostly" cancel out, but the total power is still higher with MacViews (3.34 W -> 3.65 W).

data['ScrollNoRaster']['MacViews'] = {'Gpu':2.62950, 'Gpu-IQR':0.03275,  'Cpu':1.02921, 'Cpu-IQR':0.04537,  'Pkg':3.65507, 'Pkg-IQR':0.05897, }
data['ScrollNoRaster']['Cocoa']    = {'Gpu':1.79716, 'Gpu-IQR':0.07148,  'Cpu':1.57362, 'Cpu-IQR':0.07581,  'Pkg':3.33872, 'Pkg-IQR':0.07055, }

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

commit 9eed7b76473c66cbdc5a9436c1a1a6aec851cc95
Author: Christopher Cameron <ccameron@chromium.org>
Date: Wed Aug 01 06:14:20 2018

MacViews: Push VSync parameters from RHWVMac to BridgedNativeView

This is not an appropriate long-term solution, but is a solution that
has a minimal diff and can be merged fairly easily.

The appropriate fix is to:
- make BridgedNativeView have a DisplayLink
- update that DisplayLink when the NSWindow is moved between monitors
- ensure that the VSync parameters are updated "reasonably frequently"
  to avoid skew
  - RWHVMac will poke the DisplayLink every time the renderer displays
    a new frame
  - at each poke, the DisplayLink will update its parameters if it has
    not done so in the last 10 seconds
  - this scheme will need to be revisited both for BridgedNativeView
    (because it rarely gets new frames compared to the renderer) and
    for OOP-D (because RWHVMac will no longer be informed of frames)

Such a fix is a bigger undertaking than should be merged to a branch,
so just push the VSync parameters from RWHVMac (that we would ordinarly
send to the web-contents-only ui::Compositor) to the parent ui::Layer's
compositor instead.

This will only "fix" windows that have web contents in them (which is
almost everything that will have an animation).

Bug:  869129 
Change-Id: Ie5949798aa4d1f42e73197326bca5e6e574f0843
Reviewed-on: https://chromium-review.googlesource.com/1157027
Reviewed-by: Trent Apted <tapted@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#579712}
[modify] https://crrev.com/9eed7b76473c66cbdc5a9436c1a1a6aec851cc95/content/browser/renderer_host/browser_compositor_view_mac.mm

Adding merge request for 69.

Tried testing the issue on chrome version# 70.0.3506.0(build without fix) using Mac 10.12.6 with steps mentioned below:
1) Launched chrome reported version and ran the scroll-no-raster.html file, able to see page scrolls up and down
2) Opened Devtools > performance, recorded and stopped the session and tried checking the GPU fields, but didn't find as shown in screenshot in comment# 0

Christopher Cameron@ Please find the attached screencast for your reference and let us know if we missed anything in verifying the fix.

Thanks!

Deleted: 869129.mp4 10.4 MB

	869129.mp4 10.4 MB View Download

This bug requires manual review: M69 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

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

How is the change looking in canary? Also could you ptal comment #9 from TE?

This is looking good in Canary, and my local power measurements indicate that it's fixed.

Approving merge to M69 branch 3497 based on comment #12. 

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

commit 0859b7cf198c1bad927c9785f90a872a79a91ea8
Author: Christopher Cameron <ccameron@chromium.org>
Date: Thu Aug 02 21:46:46 2018

MacViews: Push VSync parameters from RHWVMac to BridgedNativeView

This is not an appropriate long-term solution, but is a solution that
has a minimal diff and can be merged fairly easily.

The appropriate fix is to:
- make BridgedNativeView have a DisplayLink
- update that DisplayLink when the NSWindow is moved between monitors
- ensure that the VSync parameters are updated "reasonably frequently"
  to avoid skew
  - RWHVMac will poke the DisplayLink every time the renderer displays
    a new frame
  - at each poke, the DisplayLink will update its parameters if it has
    not done so in the last 10 seconds
  - this scheme will need to be revisited both for BridgedNativeView
    (because it rarely gets new frames compared to the renderer) and
    for OOP-D (because RWHVMac will no longer be informed of frames)

Such a fix is a bigger undertaking than should be merged to a branch,
so just push the VSync parameters from RWHVMac (that we would ordinarly
send to the web-contents-only ui::Compositor) to the parent ui::Layer's
compositor instead.

This will only "fix" windows that have web contents in them (which is
almost everything that will have an animation).

TBR=ccameron@chromium.org

(cherry picked from commit 9eed7b76473c66cbdc5a9436c1a1a6aec851cc95)

Bug:  869129 
Change-Id: Ie5949798aa4d1f42e73197326bca5e6e574f0843
Reviewed-on: https://chromium-review.googlesource.com/1157027
Reviewed-by: Trent Apted <tapted@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#579712}
Reviewed-on: https://chromium-review.googlesource.com/1161327
Reviewed-by: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/branch-heads/3497@{#355}
Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753}
[modify] https://crrev.com/0859b7cf198c1bad927c9785f90a872a79a91ea8/content/browser/renderer_host/browser_compositor_view_mac.mm