Browser Side Fling
19 views
Skip to first unread message
Tim Dresser
Nov 28, 2016, 2:56:29 PM11/28/16
to Sadrul Chowdhury, input-dev, sa...@chromium.org
Sadrul, do you remember what issues we ran into when attempting to move fling into the browser? Would touch and touchpad latching resolve those issues?
There are lots of inconsistencies in how touchpads are handled across platforms, and it would be nice if we could massage the touchpad data into a consistent format in the browser, to isolate the renderer from the inconsistencies. This would have some other nice properties, in terms of removing code duplication etc.
Tim
Sadrul Chowdhury
Nov 28, 2016, 4:40:24 PM11/28/16
to Tim Dresser, rjkr...@chromium.org, input-dev, sa...@chromium.org
+rjkroege@ in case I am forgetting something.
On Mon, Nov 28, 2016 at 2:56 PM, Tim Dresser <tdre...@google.com> wrote:
Sadrul, do you remember what issues we ran into when attempting to move fling into the browser? Would touch and touchpad latching resolve those issues?
From what I remember: I don't think there were any unsolvable/difficult technical issues that prevented it from happening. There were initially some discussion on whether we wanted it at all (as in, whether this would make things better/worse/not much difference), and then the owners just sort of moved onto other things.
Some relevant CLs (some WIP, some experimental) from that time in history:
Happy to talk about any of these changes if there are specific questions etc.
Sadrul
Robert Kroeger
Nov 28, 2016, 6:20:58 PM11/28/16
to Sadrul Chowdhury, Tim Dresser, input-dev, sa...@chromium.org
On Monday, November 28, 2016, Sadrul Chowdhury <sad...@chromium.org> wrote:
+rjkroege@ in case I am forgetting something.On Mon, Nov 28, 2016 at 2:56 PM, Tim Dresser <tdre...@google.com> wrote:Sadrul, do you remember what issues we ran into when attempting to move fling into the browser? Would touch and touchpad latching resolve those issues?
From what I remember: I don't think there were any unsolvable/difficult technical issues that prevented it from happening. There were initially some discussion on whether we wanted it at all (as in, whether this would make things better/worse/not much difference), and then the owners just sort of moved onto other things.Some relevant CLs (some WIP, some experimental) from that time in history:
Happy to talk about any of these changes if there are specific questions etc.
I think that mus+ash salamander will fling in DisplayCompositorHost/DisplayCompositor process as we'll have the entire LayerTreeImpl in the DisplayCompositor and it is hence natural to move the InputHandlerProxy to the DisplayCompositorHost process.
Rob.
Tim Dresser
Nov 30, 2016, 2:09:16 PM11/30/16
to Robert Kroeger, Sadrul Chowdhury, input-dev, sa...@chromium.org
Right now we sometimes fling on main, and sometimes on the compositor.
Ideally we'd deal with fling in a single place - only driving fling in the compositor / DisplayCompositor process sounds reasonable to me.
The advantage of doing this in the browser process would be that we could (at least in theory) shield all processes but the browser process from platform specific touchpad details.
Maybe we should start by just getting rid of the main thread fling path - it's possible that would actually be simpler than doing the touchpad latching work on main in addition to the compositor side implementation.
Maybe we should start by just getting rid of the main thread fling path - it's possible that would actually be simpler than doing the touchpad latching work on main in addition to the compositor side implementation.
Robert Kroeger
Dec 1, 2016, 1:51:15 PM12/1/16
to Tim Dresser, Sadrul Chowdhury, input-dev, sa...@chromium.org
On Wed, Nov 30, 2016 at 11:09 AM Tim Dresser <tdre...@google.com> wrote:
Right now we sometimes fling on main, and sometimes on the compositor.Ideally we'd deal with fling in a single place - only driving fling in the compositor / DisplayCompositor process sounds reasonable to me.The advantage of doing this in the browser process would be that we could (at least in theory) shield all processes but the browser process from platform specific touchpad details.
Maybe we should start by just getting rid of the main thread fling path - it's possible that would actually be simpler than doing the touchpad latching work on main in addition to the compositor side implementation.
This sounds reasonable to me. Presuming latching, why would a fling ever need to go to main? (I think though that we will continue to need to go to main on occasion on flingstart to determine the target scrollable.)
Tim Dresser
Dec 1, 2016, 2:43:39 PM12/1/16
to Robert Kroeger, Sadrul Chowdhury, input-dev, sa...@chromium.org
The fling still needs to be processed on main if the scroll needs to take place on main - for instance with low DPI text, or scrollers with rounded corners etc. We can generate the scroll gestures in the compositor (or browser) process though.
The target scrollable doesn't change on fling start, it latches to the current scroller.
Robert Kroeger
Dec 5, 2016, 1:37:28 PM12/5/16
to Tim Dresser, Sadrul Chowdhury, input-dev, sa...@chromium.org
On Thu, Dec 1, 2016 at 11:43 AM, Tim Dresser <tdre...@google.com> wrote:
The fling still needs to be processed on main if the scroll needs to take place on main - for instance with low DPI text, or scrollers with rounded corners etc. We can generate the scroll gestures in the compositor (or browser) process though.
Getting fling on impl with low DPI text seems highly desirable. And rounded corners (and other odd shapes given what I have learned about the MD visual roadmap.)
The target scrollable doesn't change on fling start, it latches to the current scroller.
It did this on gesture start yes?
Rob.
Tim Dresser
Dec 5, 2016, 2:48:33 PM12/5/16
to Robert Kroeger, threaded-re...@chromium.org, Sadrul Chowdhury, input-dev, sa...@chromium.org
+threaded-r...@chromium.org is working on getting more scrolling on the compositor thread.
The scroll latches during GestureScrollBegin event processing.
Timothy Dresser
Dec 5, 2016, 2:49:20 PM12/5/16
to Robert Kroeger, Sadrul Chowdhury, input-dev, sa...@chromium.org
+threaded-r...@chromium.org is working on getting more scrolling on the compositor thread.
The scroll latches during GestureScrollBegin event processing.
Majid Valipour
Dec 12, 2016, 1:12:40 PM12/12/16
to Timothy Dresser, Robert Kroeger, Sadrul Chowdhury, input-dev, sa...@chromium.org
I found this old bug with very interesting discussions on browser-side fling.
Based on my read, the main concerns were:
Based on my read, the main concerns were:
- Performance implication of a race condition between BeginFrame signal & fling IPC from browser.
- I believe this goes away once we have BeginFrame message on all platforms (issue 305237)
- The fact that this does not really remove much complexity because we have a different hit-testing (latching) semantic between touchpad & touchscreen flings events
- This is no longer an issue with our new consistent latching behavior.
- Adding lot of complexity to browser by requiring it to maintain state necessary for knowing that the fling gesture is active or not.
- This seems to be needed to correctly dispatch FlingCancel event. I don't know what is exactly involved but seems like something that we should be able to achieve by expanding out gesture ack disposition machinery.
So It seems that most of the major objections are now addresses and we should at least experiment with this next quarter.
BTW, if we are to have the fling curve run and generate GestureScrollUpdates by the Display Compositor instead of the Browser UI process then I suspect we need to send "ACK" back to this process so that it knows if the event are being consumed by renderer or not. The advantage of doing this in Browser is that it uses the existing ACK machinery instead of adding a new one.
Majid
Robert Kroeger
Dec 12, 2016, 3:24:58 PM12/12/16
to Majid Valipour, Timothy Dresser, Sadrul Chowdhury, input-dev, sa...@chromium.org
I support the idea of moving fling to the browser / windowserver.
In salamander mus/Chrome, all the cc LayerImpl state used by InputHandlerProxy will have been relocated to the compositor in the GPU process. So it doesn't make much sense to have fling be in the renderer unless it is a fling that can only be handled on main.
I'd like to see InputHandlerProxy become a component that can be connected to the future LayerCompositorHost.
On Mon, Dec 12, 2016 at 10:12 AM, Majid Valipour <maj...@chromium.org> wrote:
I found this old bug with very interesting discussions on browser-side fling.
Based on my read, the main concerns were:
- Performance implication of a race condition between BeginFrame signal & fling IPC from browser.
- I believe this goes away once we have BeginFrame message on all platforms (issue 305237)
BeginFrame everywhere is PoR. And I believe is nearly done. And: the events should be bundled with the BegnFrame? Or at least in a phase-shifted bundle scheduled w.r.t. to it?
- The fact that this does not really remove much complexity because we have a different hit-testing (latching) semantic between touchpad & touchscreen flings events
- This is no longer an issue with our new consistent latching behavior.
w00t! I've wanted unified semantics between touchpad and touchscreen for a while (e.g. https://bugs.webkit.org/show_bug.cgi?id=80596)
- Adding lot of complexity to browser by requiring it to maintain state necessary for knowing that the fling gesture is active or not.
- This seems to be needed to correctly dispatch FlingCancel event. I don't know what is exactly involved but seems like something that we should be able to achieve by expanding out gesture ack disposition machinery.
FWIW: GestureEventQueue has code to track if flings are in progress so the complexity exists in the browser.
So It seems that most of the major objections are now addresses and we should at least experiment with this next quarter.
+1
BTW, if we are to have the fling curve run and generate GestureScrollUpdates by the Display Compositor instead of the Browser UI process then I suspect we need to send "ACK" back to this process so that it knows if the event are being consumed by renderer or not. The advantage of doing this in Browser is that it uses the existing ACK machinery instead of adding a new one.
I don't understand what you mean. Maybe you can explain? The DisplayCompositor shouldn't be generating GestureScrollUpdate events. I suspect that we want a ui component hosted in musws or the browser to be generating the fling and sending events to renderers or the gpu process as specified by metadata for the target scrollable.
Rob.
Majid
On Mon, Dec 5, 2016 at 2:49 PM Timothy Dresser <tdre...@chromium.org> wrote:
+threaded-rendering-dev@chromium.org is working on getting more scrolling on the compositor thread.
Reply all
Reply to author
Forward
0 new messages