Fling cancellation

[Sami Kyostila]

We were looking at some traces and noticed that sometimes fling cancellation can be badly delayed. I *think* this is because the tap that cancelled the fling landed on a touch handler and caused this sequence of events:

1. TouchStart

2. Long delay before the main thread runs the touchstart handler.

3. GestureFlingCancel => fling animation stops

The long delay is partly due to a scheduler bug (we don't prioritize main thread input because we're already flinging in the compositor), but I was also wondering if it's necessary to block the FlingCancel on the handling of the TouchStart?

- Sami

[Tim Dresser]

I think the optimal behavior here does require waiting to see if the TouchStart is handled, but what we currently do is nowhere close to optimal.

A gesture falls into one of 4 categories:

1. Cancelling non-preventDefaulted

2. Cancelling preventDefaulted

3. Non-cancelling non-preventDefaulted

4. Non-cancelling preventDefaulted

I think ideally we would cancel the fling in every case except case 3. In order to do this, we need to know whether or not the events were preventDefaulted. I believe that our current approach is to cancel the fling in case 1 only.

If we ignore the touch disposition, we could cancel the fling in cases 1 and 2, which seems like it's more correct than what we do now, and has better performance implications.

[Sami Kyostila]

I see, we need to give the touch handler the opportunity to override the cancellation of the fling, is that right? I guess I've never really run into content that does that. My naive hope was that we'd always be able to unconditionally cancel the fling.

I think we can improve things a little with better scheduling, but it'd be best if we could avoid the main trip round trip completely.

- Sami

To unsubscribe from this group and stop receiving emails from it, send an email to input-dev+...@chromium.org.

[Timothy Dresser]

A motivating example: when a user repeatedly flings, we don't cancel the proceeding fling when a new fling starts. If a page consumes one of the flings, we should probably cancel the proceeding fling.

+Jared Duke, who may have thoughts here. 

[Rick Byers]

In general I think it's fine for the page not to be able to suppress fling cancellation.  Conceptually we cancel fling because the user has touched the screen (with the special exception for fling boosting), so in principle I think the touch disposition shouldn't really matter.  If it wasn't for fling boosting then perhaps this could be really easy now that we have eager GR - just send a GestureFlingCancel immediately on touchstart (before even sending the touchstart itself).

I forget the details of how fling boosting works wrt. GFC, but presumably for a great fling boosting experience we don't really have a choice but to delay fling cancellation, right?  Eg. we really don't want to see the fling stop between the first and second one when there is a touch handler and janky main thread, right?

Rick

[Timothy Dresser]

I agree that pages shouldn't be able to suppress fling cancellation. I think they should be able to cause fling cancellation though, as in my example above of a consumed fling during a sequence of flings.

We do need to delay fling cancellation until we can tell if a gesture boost a fling or not. We could, for example, send a GFC on tap before receiving acks for the touch events composing the tap.

[Jared Duke]

I actually don't believe we *ever* suppress fling cancellation. We always dispatch a GestureFlingCancel at the start of a touch sequence if the previous touch sequence resulted in a fling. However, as Sami has observed, we wait until we receive the ack for the first touch event before forwarding the GestureFlingCancel.

There are two time-sensitive behaviors that are more likely to break if we were to forward the GFC in parallel with the touch. Rick mentioned fling boosting, but tap suppression (during a fling) is also sensitive to the time between the GestureFlingCancel and the subsequent GestureTapDown. We might be able to make tap suppression more robust, but fling boosting is trickier because any kind of delay between events "starves" the flywheel motion. I suppose if the main thread is blocked the user might have bigger complaints than either of these two features not working.

Sami, you're saying the existence of a fling on the compositor prevents us from prioritizing main thread input? Shouldn't observation of the touchstart kick us into the most elevated form of main thread input prioritization?

Outside of scheduling, I suppose the main benefit to sending the GFC earlier would be to make it feel as if the page is more responsive (particularly if the user taps, the fling would terminate sooner)?

[Sami Kyostila]

2015-08-25 16:27 GMT+01:00 Jared Duke <jdd...@chromium.org>:

I actually don't believe we *ever* suppress fling cancellation. We always dispatch a GestureFlingCancel at the start of a touch sequence if the previous touch sequence resulted in a fling. However, as Sami has observed, we wait until we receive the ack for the first touch event before forwarding the GestureFlingCancel.

There are two time-sensitive behaviors that are more likely to break if we were to forward the GFC in parallel with the touch. Rick mentioned fling boosting, but tap suppression (during a fling) is also sensitive to the time between the GestureFlingCancel and the subsequent GestureTapDown. We might be able to make tap suppression more robust, but fling boosting is trickier because any kind of delay between events "starves" the flywheel motion. I suppose if the main thread is blocked the user might have bigger complaints than either of these two features not working.

Sami, you're saying the existence of a fling on the compositor prevents us from prioritizing main thread input? Shouldn't observation of the touchstart kick us into the most elevated form of main thread input prioritization?

Yep, just reporting here that we figured offline that this was in fact a bug in the scheduler and a fix is forthcoming.

 

Outside of scheduling, I suppose the main benefit to sending the GFC earlier would be to make it feel as if the page is more responsive (particularly if the user taps, the fling would terminate sooner)?

That's right. The effect isn't quite as bad as with a scroll start since the fling animation continues smoothly, but it's a little uncanny when the page continues to move even though your finger is on the glass.

It sounds like moving the GFC earlier isn't without problems, so we might want to just make sure we prioritize input and leave it at that (fixing the scheduling does make a visible difference btw).

- Sami