|
|
DescriptionDon't throttle touch events on resent GestureScrollUpdates.
Touch events are currently throttled during GestureScrolls to avoid
overloading a page's touch handler. However, in the event we are
resending a GestureScroll to a GuestView's host based on a touch handler
in the Guest, this leads to extremely janky scroll performance.
This CL detects when a GestureScroll is being resent, and turns off
throttling in this case.
BUG=491940
Committed: https://crrev.com/1ab6149f525fc879dbc068d047501ca715a589d6
Cr-Commit-Position: refs/heads/master@{#351804}
Patch Set 1 #
Total comments: 1
Patch Set 2 : Ignore re-sent GestureScrollUpdates. #
Total comments: 2
Patch Set 3 : Fix brace indent. #
Depends on Patchset: Messages
Total messages: 21 (7 generated)
The CQ bit was checked by wjmaclean@chromium.org to run a CQ dry run
wjmaclean@chromium.org changed reviewers: + tdresser@chromium.org
tdresser@ - Does this look sane?
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1383633002/1 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1383633002/1
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
jdduke@chromium.org changed reviewers: + jdduke@chromium.org
https://chromiumcodereview.appspot.com/1383633002/diff/1/content/browser/rend... File content/browser/renderer_host/input/touch_event_queue.cc (right): https://chromiumcodereview.appspot.com/1383633002/diff/1/content/browser/rend... content/browser/renderer_host/input/touch_event_queue.cc:640: send_touch_events_async_ = (gesture_event.event.resendingPluginId == -1); Can't the resending and non-resending events be interleaved? So then shouldn't we just ignore GSU's that have an invalid resendingPluginId (rather than turning the asyns sending on/off)?
On 2015/09/30 20:26:46, jdduke wrote: > https://chromiumcodereview.appspot.com/1383633002/diff/1/content/browser/rend... > File content/browser/renderer_host/input/touch_event_queue.cc (right): > > https://chromiumcodereview.appspot.com/1383633002/diff/1/content/browser/rend... > content/browser/renderer_host/input/touch_event_queue.cc:640: > send_touch_events_async_ = (gesture_event.event.resendingPluginId == -1); > Can't the resending and non-resending events be interleaved? So then shouldn't > we just ignore GSU's that have an invalid resendingPluginId (rather than turning > the asyns sending on/off)? Events are only resent from a guest to an embedder. Each guest has its own GestureRecognizer, and also TouchEventQueue (TEQ). My current thinking is that we won't be getting interleaving in a single TEQ, though the different queues will possibly have different values for send_touch_events_async_. We *may* need to find a way to turn off throttling in the *guest's* TEQ when it's turned off in the host's to completely get rid of the jitter.
On 2015/09/30 20:53:06, wjmaclean wrote: > Events are only resent from a guest to an embedder. Each guest has its own > GestureRecognizer, and also TouchEventQueue (TEQ). My current thinking is that > we won't be getting interleaving in a single TEQ, though the different queues > will possibly have different values for send_touch_events_async_. We *may* need > to find a way to turn off throttling in the *guest's* TEQ when it's turned off > in the host's to completely get rid of the jitter. I see, so would it be safe to just ignore GSU's (for the sake of sync scrolling) that have a valid plugin ID? I assume the parent would be the one responsible for throttling in such cases?
On 2015/09/30 22:04:55, jdduke wrote: > On 2015/09/30 20:53:06, wjmaclean wrote: > > Events are only resent from a guest to an embedder. Each guest has its own > > GestureRecognizer, and also TouchEventQueue (TEQ). My current thinking is that > > we won't be getting interleaving in a single TEQ, though the different queues > > will possibly have different values for send_touch_events_async_. We *may* > need > > to find a way to turn off throttling in the *guest's* TEQ when it's turned off > > in the host's to completely get rid of the jitter. > > I see, so would it be safe to just ignore GSU's (for the sake of sync scrolling) > that have a valid plugin ID? I assume the parent would be the one responsible > for throttling in such cases? I think we should safely be able to ignore GSU's with a valid plugin id. I agree that it seems like a safer approach.
Just to clarify, is this (Patchset #2) what you meant by "ignore"?
The CQ bit was checked by wjmaclean@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1383633002/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1383633002/20001
Yup! LGTM with nit. https://chromiumcodereview.appspot.com/1383633002/diff/20001/content/browser/... File content/browser/renderer_host/input/touch_event_queue.cc (right): https://chromiumcodereview.appspot.com/1383633002/diff/20001/content/browser/... content/browser/renderer_host/input/touch_event_queue.cc:658: } Indentation looks a little off here.
The CQ bit was checked by wjmaclean@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from tdresser@chromium.org Link to the patchset: https://chromiumcodereview.appspot.com/1383633002/#ps40001 (title: "Fix brace indent.")
Thanks! https://chromiumcodereview.appspot.com/1383633002/diff/20001/content/browser/... File content/browser/renderer_host/input/touch_event_queue.cc (right): https://chromiumcodereview.appspot.com/1383633002/diff/20001/content/browser/... content/browser/renderer_host/input/touch_event_queue.cc:658: } On 2015/10/01 13:55:05, tdresser wrote: > Indentation looks a little off here. Done.
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1383633002/40001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1383633002/40001
Message was sent while issue was closed.
Committed patchset #3 (id:40001)
Message was sent while issue was closed.
Patchset 3 (id:??) landed as https://crrev.com/1ab6149f525fc879dbc068d047501ca715a589d6 Cr-Commit-Position: refs/heads/master@{#351804} |