diff options
author | skyostil@chromium.org <skyostil@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-11-27 17:24:16 +0000 |
---|---|---|
committer | skyostil@chromium.org <skyostil@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-11-27 17:24:16 +0000 |
commit | e3be2765447759c286f7004fade76d8a47c90f82 (patch) | |
tree | 1f58c17a40aa72ecb826374fbf6c0f8c24a5671d /android_webview | |
parent | db31213f816c6e805315fd109c2cf52633df9fd9 (diff) | |
download | chromium_src-e3be2765447759c286f7004fade76d8a47c90f82.zip chromium_src-e3be2765447759c286f7004fade76d8a47c90f82.tar.gz chromium_src-e3be2765447759c286f7004fade76d8a47c90f82.tar.bz2 |
android: Clean up BeginFrame generation for input events
This patch removes the generation of synthetic BeginFrame messages for
specific input events. This code was used to reduce the latency of
responding to scroll events from an idle state. Essentially it allowed
us to service the first SetNeedsBeginFrame message sent by the renderer
within the current vsync interval instead of waiting for the next one.
This patch solves the same problem in a simpler way. For every touch
event ContentViewCore receives, we subscribe to a single vsync
notification. Since touch events that result in rendering are commonly
not the first event in the sequence (e.g., TouchMove instead of
TouchDown), this ensures the BeginFrame for the provoking touch event
(e.g., TouchMove) has already been requested by an earlier touch event
(e.g., TouchDown).
The reason we can avoid having to send all input events for the current
frame before the BeginFrame is that the renderer can deal with receiving
these messages out of order thanks to deadline scheduling.
One corner case with this scheme is when the very first touch event
results in rendering. In that case the vsync notification is idle, so
the next vsync notification would get sent at the beginning of the
following frame interval. This will be dealt with an upcoming patch that
triggers the vsync immediately when started from idle.
With the above changes the latency for touch input handlers is brought
down to a comparable level with scroll updates. Removing the synthetic
BeginFrame generation also fixes an issue with synthetic touch gestures
resulting in two BeginFrames getting sent during one frame.
BUG=256744,321245
Review URL: https://codereview.chromium.org/88623002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@237594 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'android_webview')
-rw-r--r-- | android_webview/java/src/org/chromium/android_webview/AwContents.java | 5 |
1 files changed, 1 insertions, 4 deletions
diff --git a/android_webview/java/src/org/chromium/android_webview/AwContents.java b/android_webview/java/src/org/chromium/android_webview/AwContents.java index fabb027..ae5aad9 100644 --- a/android_webview/java/src/org/chromium/android_webview/AwContents.java +++ b/android_webview/java/src/org/chromium/android_webview/AwContents.java @@ -545,13 +545,10 @@ public class AwContents { ContentViewCore.ZoomControlsDelegate zoomControlsDelegate) { Context context = containerView.getContext(); ContentViewCore contentViewCore = new ContentViewCore(context); - // Note INPUT_EVENTS_DELIVERED_IMMEDIATELY is passed to avoid triggering vsync in the - // compositor, not because input events are delivered immediately. contentViewCore.initialize(containerView, internalDispatcher, nativeWebContents, context instanceof Activity ? new ActivityWindowAndroid((Activity) context) : - new WindowAndroid(context.getApplicationContext()), - ContentViewCore.INPUT_EVENTS_DELIVERED_IMMEDIATELY); + new WindowAndroid(context.getApplicationContext())); contentViewCore.setGestureStateListener(pinchGestureStateListener); contentViewCore.setContentViewClient(contentViewClient); contentViewCore.setZoomControlsDelegate(zoomControlsDelegate); |