summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
author Grace Kloba <klobag@google.com> 2009-06-26 11:36:03 -0700
committer Grace Kloba <klobag@google.com> 2009-06-26 11:36:03 -0700
commit53d3c1e4513135c5d8f70da4938c7d25455263f5 (patch)
tree8de7779644de57a9f5576382fc121f5efe5fccda
parentef7b5d6da57b434a739c8e8261dab9380a57e2f9 (diff)
Fine tune TOUCH_SENT_INTERVAL for the high speed devices.
-rw-r--r--core/java/android/webkit/WebView.java13
1 files changed, 11 insertions, 2 deletions
diff --git a/core/java/android/webkit/WebView.java b/core/java/android/webkit/WebView.java
index 97134d22807c..5f002491865b 100644
--- a/core/java/android/webkit/WebView.java
+++ b/core/java/android/webkit/WebView.java
@@ -329,9 +329,18 @@ public class WebView extends AbsoluteLayout
/**
* The minimum elapsed time before sending another ACTION_MOVE event to
- * WebViewCore
+ * WebViewCore. This really should be tuned for each type of the devices.
+ * For example in Google Map api test case, it takes Dream device at least
+ * 150ms to do a full cycle in the WebViewCore by processing a touch event,
+ * triggering the layout and drawing the picture. While the same process
+ * takes 60+ms on the current high speed device. If we make
+ * TOUCH_SENT_INTERVAL too small, there will be multiple touch events sent
+ * to WebViewCore queue and the real layout and draw events will be pushed
+ * to further, which slows down the refresh rate. Choose 50 to favor the
+ * current high speed devices. For Dream like devices, 100 is a better
+ * choice. Maybe make this in the buildspec later.
*/
- private static final int TOUCH_SENT_INTERVAL = 100;
+ private static final int TOUCH_SENT_INTERVAL = 50;
/**
* Helper class to get velocity for fling