[Webkit-unassigned] [Bug 77477] [chromium] Process scroll-gesture events from the MT compositor

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=77477





--- Comment #15 from James Robinson <jamesr at chromium.org>  2012-02-03 13:01:16 PST ---
Gah, I realize my mistake now!  Sorry to mislead for the last several comments.

To start, the caller should never send a GestureScrollUpdate (or any type of input event) before the previous input event is ACK'd.  I believe that we propagate the disposition of the scroll in the reply to the GestureScrollBegin, correct?  So I guess the three cases are:

(1) we've decided to accept the scroll on the compositor thread, in which case we accept the input on the thread and expect take a sequence of GestureScrollUpdates followed by a GestureScrollEnd.

(2) we've decided not to accept the scroll on the compositor thread, but the main thread might want to accept it. in this case, the input handler calls didNotHandleInputEvent(true) and then has to forward all subsequence GestureScrollUpdates up to and including the GestureScrollEnd to the main thread. I think this is what your patch (correctly) does.

(3) we've decided not to scroll on the compositor thread and we know we also don't want to scroll on the main thread. there are two possibilities here: either we tell the browser side to not send any more gesture events at all for this GestureScroll, or the browser still sends them and we ignore them.  I'm not sure which behavior this patch is trying to adopt.

So the question is then what happens for (3) - do we expect to get the GestureScrollUpdates / GestureScrollEnd and ignore them, or is the caller supposed to not generate those? I think it'd be more efficient if the browser was smart enough not to send these to the renderer at all but that might be tricky.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.