summaryrefslogtreecommitdiffstats
path: root/android_webview
diff options
context:
space:
mode:
authorskyostil@chromium.org <skyostil@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2013-11-27 17:24:16 +0000
committerskyostil@chromium.org <skyostil@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2013-11-27 17:24:16 +0000
commite3be2765447759c286f7004fade76d8a47c90f82 (patch)
tree1f58c17a40aa72ecb826374fbf6c0f8c24a5671d /android_webview
parentdb31213f816c6e805315fd109c2cf52633df9fd9 (diff)
downloadchromium_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.java5
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);