[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 #16 from sadrul at chromium.org  2012-02-03 14:05:14 PST ---
Sorry for not explaining this better in my previous attempt.

(In reply to comment #15)
> 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.

Interesting. I hadn't considered (3). With this change for case (3), gesture events will continue to come in, and the events will simply be ignored here. I think this is a safe way of dealing with the events. Right now, when the MT compositor is not in use, the browser always send all the gesture events, and they are processed/ignored as appropriate by Webkit. So this behaviour will match that.

Having said that, I like your idea of not sending gesture update/end if gesture-begin didn't initiate a scroll. From what I can see, this will need to happen in chrome (CompositorThread/InputEventFilter). I will look into implementing that now. If I can get this to work before https://bugs.webkit.org/show_bug.cgi?id=73350 lands, then I will update this patch here.

Thanks for your suggestions!

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