diff options
| author | jamesr@chromium.org <jamesr@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-03-28 21:10:24 +0000 |
|---|---|---|
| committer | jamesr@chromium.org <jamesr@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-03-28 21:10:24 +0000 |
| commit | 7a1ec28a5ed31296639e95bdf69b844cb626a50f (patch) | |
| tree | ff41102607b3056433586be20c08bd87828c56a0 /webkit/fileapi | |
| parent | 10c5623f391421794d2b341485cceeb16813a3d4 (diff) | |
| download | chromium_src-7a1ec28a5ed31296639e95bdf69b844cb626a50f.zip chromium_src-7a1ec28a5ed31296639e95bdf69b844cb626a50f.tar.gz chromium_src-7a1ec28a5ed31296639e95bdf69b844cb626a50f.tar.bz2 | |
Implement active wheel fling transfer via WebCompositorInputHandlerClient
There are cases where we'll process a GestureFlingStart event on the
compositor thread, initiate a wheel fling, and then later determine that
we can't process the rest of the animation on the compositor thread. One
example of where this could happen is if the page registers a mousewheel
JS event listener while the fling is in progress. In this case, we need
to transfer the animation to the WebView to process so it can generate
the correct events.
This implements the transfer as a call out via the
WebCompositorInputHandlerClient. I think this is a reasonable place to
put the interface, since it's intimately related with the input
processing stream.
BUG=don't have handy, but there is one
TEST=wheel fling on CrOS should work with --enable-threaded-compositing
Review URL: http://codereview.chromium.org/9802006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@129487 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'webkit/fileapi')
0 files changed, 0 insertions, 0 deletions