1229839 - Fling deceleration with C++ APZ is too slow

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Toolbar, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

From https://groups.google.com/d/msg/mozilla.dev.platform/zdOIK5fxmFA/4xXp4K0XCwAJ

----
2. Deceleration takes too long to happen (the page seems to just float for far too long after flings happen, especially for slower, smaller flings). It's much slower than other apps, and it also feels much slower than I remember for Firefox before the update.
----

I agree with this, we need to tweak the physics constants to get it more in line with Android behaviour.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

This is probably the best one to tackle first. The relevant prefs to tweak here are:

1) apz.fling_stopped_threshold
   Description: When flinging, if the velocity goes below this number, we just stop the animation completely. This is to prevent asymptotically approaching 0 velocity and rerendering unnecessarily. The higher this value, the sooner the fling will stop.
   Units: screen pixels per millisecond
   Current default value: 0.05

2) apz.fling_friction
   Description: Amount of friction applied during flings. This is used in the following formula: v(t1) = v(t0) * (1 - f)^(t1 - t0), where v(t1) is the velocity for a new sample, v(t0) is the velocity at the previous sample, f is the value of this pref, and (t1 - t0) is the amount of time, in milliseconds, that has elapsed between the two samples. Another way of putting is that for the default friction value of 0.0019, we multiply the velocity by 0.9981 every millisecond.
   Current default value: 0.0019

If you have a velocity vs time curve like the below, the apz.fling_friction affects the shape of the curve (higher values will drop to zero faster) and the apz.fling_stopped_threshold will affect at what y-value the curve will stop (higher values means the cutoff will be further on the left).

         ^ X
         | X
         | XXX
         |   XXXXX
Velocity |       XXXXXX
         |             XXXXXXXXXX
         |                      XXXXXXXXXXX
         |                                XXX
         +----------------------------------->
                   Time

Note that these prefs will be "live" (no restart required) after bug 1232094 gets merged to m-c.

Comment 2

[James Willcox (:snorp) ([e-mail]) (he/him)]

I'm using 0.0040 locally for apz.fling_friction and it feels pretty good to me.

Comment 3

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #2)
> I'm using 0.0040 locally for apz.fling_friction and it feels pretty good to
> me.

Can we get a build to test and compare this against our current Nightly?

Comment 4

[Kartikaya Gupta (email:[e-mail])]

You can just set the pref in your existing nightly build using about:config - no special build is required.

Comment 5

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

I've been messing around with these values a bit and ultimately settled on the following:

apz.fling_stopped_threshold: 0.1
apz.fling_friction: 0.004

When I compare it to native apps like Twitter and Chrome, it feels pretty close.

---

But as I test this more, I'm realizing that there are two main types of scrolling:

1) "nudges" that users will use to read the next line, more precise.
2) "throws" that users tend to use to get to the bottom/top of a page, less precise.

I think the numbers I described above help with the first scenario, but causes some problems with the second. 

IIRC, in Orlando, we talked about "throws", am I correct in assuming that there are numbers/prefs just handling the "throwing"? I think that's the last piece of the puzzle for this bug. 

Thoughts?

Comment 6

[Kartikaya Gupta (email:[e-mail])]

Yup, for the "throws" cases we've got other prefs to fiddle with, as part of bug 1229841. I'll post detailst here. It may be that after changing those we may want to tweak these more because of how they're somewhat interdependent, but we can start with that.

I'll put up a patch to change the prefs you requested, and post more prefs and their descriptions to bug 1229841.

Comment 7

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #6)
> Yup, for the "throws" cases we've got other prefs to fiddle with, as part of
> bug 1229841. I'll post detailst here. It may be that after changing those we
> may want to tweak these more because of how they're somewhat interdependent,
> but we can start with that.
> 
> I'll put up a patch to change the prefs you requested, and post more prefs
> and their descriptions to bug 1229841.

Thanks Kats! just NI me where needed :) 

Is the "throws" bug the last part of this work?

Comment 8

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

^

Comment 9

[Kartikaya Gupta (email:[e-mail])]

There's also axis locking (bug 1226655) and the panning threshold (bug 1230709).

Comment 10

[Kartikaya Gupta (email:[e-mail])]

Attachment: Patch

Comment 11

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/3c8ac1915f9b

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/3c8ac1915f9b