Closed Bug 1229839 Opened 7 years ago Closed 7 years ago

Fling deceleration with C++ APZ is too slow

Categories

(Firefox for Android Graveyard :: Toolbar, defect)

45 Branch
All
Android
defect
Not set
normal

Tracking

(firefox46 fixed)

RESOLVED FIXED
Firefox 46
Tracking Status
firefox46 --- fixed

People

(Reporter: kats, Assigned: kats)

References

Details

(Whiteboard: [pref-tweak])

Attachments

(1 file)

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.
Whiteboard: [pref-tweak]
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.
Flags: needinfo?(alam)
I'm using 0.0040 locally for apz.fling_friction and it feels pretty good to me.
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) 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?
Flags: needinfo?(snorp)
Flags: needinfo?(bugmail.mozilla)
Flags: needinfo?(alam)
You can just set the pref in your existing nightly build using about:config - no special build is required.
Flags: needinfo?(bugmail.mozilla)
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?
Flags: needinfo?(bugmail.mozilla)
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.
Flags: needinfo?(bugmail.mozilla)
Assignee: nobody → bugmail.mozilla
Version: Trunk → Firefox 45
(In reply to Kartikaya Gupta (email:kats@mozilla.com) 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?
^
Flags: needinfo?(bugmail.mozilla)
There's also axis locking (bug 1226655) and the panning threshold (bug 1230709).
Flags: needinfo?(bugmail.mozilla)
Attached patch PatchSplinter Review
Attachment #8704348 - Flags: review?(snorp)
Attachment #8704348 - Flags: review?(snorp) → review+
https://hg.mozilla.org/mozilla-central/rev/3c8ac1915f9b
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 46
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.