cc: Disable LastInputEventForBeginFrame

cc: Disable LastInputEventForBeginFrame

The LastInputEventForBeginFrame optimization makes reasoning
about ordering and scheduling more difficult.

Disabling it for now.

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

[brianderson, 2013-06-05 02:20:23]

ptal

[Sami, 2013-06-05 10:01:18]

lgtm.

One side effect of this change that I think we didn't discuss is that it will
increase input latency by one frame. This is because the SetNeedsBeginFrame
request from the renderer will be served at the next vsync instead of the
current one.

For example see this trace starting from where the scroll offset starts
increasing (taken with this patch applied):
https://docs.google.com/a/google.com/file/d/0B7i1yhITiW6lVUxLeDRVSnpURVk/edit...

I think it's fine to regress temporarily, but let's also open a bug to make it
better again :) I did a quick search and didn't find one -- sorry if I missed
it.

https://codereview.chromium.org/15651006/diff/26001/content/public/android/ja...
File
content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java
(right):

https://codereview.chromium.org/15651006/diff/26001/content/public/android/ja...
content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:1200:
// BeginFrame early. BUG 245438.
Nit: crbug.com/245438. Should we open another bug for this one since presumably
that one will be closed one this patch lands? :)

[brianderson, 2013-06-05 17:44:37]

Sami, I've opened crbug 247043 as a followup.

[commit-bot: I haz the power, 2013-06-05 17:44:52]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/brianderson@chromium.org/15651006/42001

[commit-bot: I haz the power, 2013-06-05 17:52:10]

Retried try job too often on chromium_presubmit for step(s) presubmit
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=chromium_p...

[brianderson, 2013-06-05 17:54:24]

+jamesr for OWNERS review of content.

[jamesr, 2013-06-05 18:06:40]

I'm not a content/ owner. I am a content/renderer/ owner, and that part LGTM
with one change

https://chromiumcodereview.appspot.com/15651006/diff/42001/content/renderer/g...
File content/renderer/gpu/input_handler_proxy.cc (right):

https://chromiumcodereview.appspot.com/15651006/diff/42001/content/renderer/g...
content/renderer/gpu/input_handler_proxy.cc:55: return
HandleInputEventInternal(event);
hmm, well now there's no reason at all for the HandleInputEvent /
HandleInputEventInternal distinction. could you fold these together, please?

[brianderson, 2013-06-05 18:23:18]

Thanks James.

+yfriedman for OWNERS review of content/browser and content/public/android.

[Yaron, 2013-06-05 18:39:00]

On 2013/06/05 18:23:18, Brian Anderson wrote:
> Thanks James.
> 
> +yfriedman for OWNERS review of content/browser and content/public/android.

lgtm assuming 247043 is next on deck and expected to land before 29. Otherwise
it's not clear why we'd knowingly accept an extra frame of input latency

[brianderson, 2013-06-05 18:44:38]

On 2013/06/05 18:39:00, Yaron wrote:
> On 2013/06/05 18:23:18, Brian Anderson wrote:
> > Thanks James.
> > 
> > +yfriedman for OWNERS review of content/browser and content/public/android.
> 
> lgtm assuming 247043 is next on deck and expected to land before 29. Otherwise
> it's not clear why we'd knowingly accept an extra frame of input latency

We will land a fix for 247043 before m29. This patch is blocking a large
refactoring patch to bring the scheduling of other platforms and Android closer
together. After the refactoring patch lands, we will re-implement this
optimization for Android.

[commit-bot: I haz the power, 2013-06-05 18:46:18]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/brianderson@chromium.org/15651006/52001

[commit-bot: I haz the power, 2013-06-06 02:22:20]

Change committed as 204383