Defer scroll offset change notification to browser

Defer scroll offset change notification to browser

When the main frame's scroll offset changes, we notify the browser
about this using ViewHostMsg_DidChangeScrollOffset. It turns out that
1) sending this message immediately makes the renderer main thread very
likely to become descheduled, and 2) this notification is only used
for hiding the mouse cursor when the page starts scrolling.

Since this signal isn't latency sensitive (and there are other
mechanisms for low latency scroll synchronization), we can defer sending
it until the current frame has been composited and we're otherwise idle.
Doing this reduces the average duration of ScrollableArea::
scrollPositionChanged on from 0.5 ms to 0.2 ms on a Nexus 5.

Trace before:
https://drive.google.com/open?id=0ByyxMXB38gLDRUY1VFJvZFFhVHc&authuser=1

Trace after:
https://drive.google.com/open?id=0ByyxMXB38gLDX1VwWmxvbTRBWWc&authuser=1

BUG=359566
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=289898

[jamesr, 2014-08-14 17:16:52]

This is also used by autofill (which should work fine) and by the android
webview code to do something that isn't entirely clear to me (see
SynchronousCompositorImpl::DidChangeRootLayerScrollOffset).  Are you sure that
case can be delayed as well?

[jamesr, 2014-08-14 17:16:58]

This is also used by autofill (which should work fine) and by the android
webview code to do something that isn't entirely clear to me (see
SynchronousCompositorImpl::DidChangeRootLayerScrollOffset).  Are you sure that
case can be delayed as well?

[Sami, 2014-08-14 17:29:29]

On 2014/08/14 17:16:58, jamesr wrote:
> This is also used by autofill (which should work fine) and by the android
> webview code to do something that isn't entirely clear to me (see
> SynchronousCompositorImpl::DidChangeRootLayerScrollOffset).  Are you sure that
> case can be delayed as well?

Hmm, I don't that is connected to this notification. Martin pointed out that
DidChangeRootLayerScrollOffset goes the other way -- from browser to cc impl --
whereas this is from renderer to browser. I didn't see the autofill code either
-- can you point me to it?

[jamesr, 2014-08-14 17:31:00]

There's a content public notification:

https://code.google.com/p/chromium/codesearch#chromium/src/content/public/ren...

registered here:

https://code.google.com/p/chromium/codesearch#chromium/src/components/autofil...

it just hides a popup, don't think it needs to be timed super carefully
(although it might look weird for the page to move underneath the autofill
popup).  Maybe worth trying locally to see how it feels?

[Sami, 2014-08-14 17:48:59]

On 2014/08/14 17:31:00, jamesr wrote:
> There's a content public notification:
> 
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/public/ren...
> 
> registered here:
> 
>
https://code.google.com/p/chromium/codesearch#chromium/src/components/autofil...
> 
> it just hides a popup, don't think it needs to be timed super carefully
> (although it might look weird for the page to move underneath the autofill
> popup).  Maybe worth trying locally to see how it feels?

Ah, gotcha. This patch doesn't change the timing of that since the observers are
still called directly from RenderViewImpl::didChangeScrollOffset.

[jamesr, 2014-08-14 18:02:16]

Ah right, that's renderer.

lgtm but please confirm the android webview usage before landing

[mkosiba (inactive), 2014-08-14 19:08:37]

lgtm, it doesn't look like the webview uses this message.

[Sami, 2014-08-15 09:26:35]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2014-08-15 09:27:55]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/skyostil@chromium.org/473953002/1

[commit-bot: I haz the power, 2014-08-15 16:20:49]

Committed patchset #1 (1) as 289898