Quick flings don't fling as much with C++ APZ

RESOLVED FIXED in Firefox 46

Status

()

Firefox for Android
Toolbar
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: kats, Assigned: kats)

Tracking

Trunk
Firefox 46
All
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox45 affected, firefox46 fixed)

Details

(Whiteboard: [pref-tweak])

Attachments

(1 attachment)

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

----
3. Quick flings don't jump up or down on the page as quickly as they previously did, making more work to get back up to the top of a page, or to quickly jump down to read the summary paragraph of an article.
----

For this we probably just need to adjust the fling curve and fling acceleration prefs to make sure it doesn't slow down too fast.
Whiteboard: [pref-tweak]
Depends on: 1231504
Depends on: 1232094
No longer depends on: 1232094
I'm using apz.fling_accel_base_mult = 2.0 locally and that seems to be enough to let me fling very far when I want to.
I think the initial fling needs to be faster, still, but the 2.0 makes multiple flings better?
So there's two sets of prefs that are relevant for tweaking this behaviour. The first is the "fling acceleration" set of prefs. "Fling acceleration" is when you do multiple flings in a row with your finger, and the velocity of the second fling onwards is accelerated beyond what you can do with your finger alone. The prefs that control this behaviour are:

apz.fling_accel_interval_ms

This is the time in milliseconds that determines whether a second fling will be treated as accelerated. If two flings are started within this interval, the second one will be accelerated. Setting an interval of 0 means that acceleration will be disabled.

apz.fling_accel_base_mult and apz.fling_accel_supplemental_mult

When applying an acceleration on a fling, the new computed velocity is (new_fling_velocity * base_mult) + (old_velocity * supplemental_mult). The base_mult and supplemental_mult multiplier values are controlled by these prefs. Note that "old_velocity" here is the initial velocity of the previous fling _after_ acceleration was applied to it (if applicable).

So to give you a numerical example of how this works, say you have fling_accel_interval_ms set to 500ms, fling_accel_base_mult set to 1.5 and fling_accel_supplemental_mult set to 2.0. Then you start a fling at say 100 pixels/second. 300ms later, the fling has slowed down to 50 pixels/second, and you do another fling with your finger moving at 75 pixels/second. Since 300ms < 500ms, this second fling will be accelerated using the formula given above:
computed velocity = (new_fling_velocity * base_mult) + (old_velocity * supplemental_mult)
 = (75 * 1.5) + (50 * 2.0)
 = 212.5 pixels/second.

So for the second fling, even though your finger was moving at 75 pixels/second, it gets accelerated to 212.5 pixels/second. This behaviour is useful for the "get to the bottom of the page as fast as possible" use case where the user just flings like crazy.


The second set of prefs is for "fling curving". With fling curving, the fling speed is adjusted so that it isn't exactly what your finger was moving at. Instead, there is a function (a bezier curve) that maps the finger velocity to the "visual" velocity. This allows you make slow flings slower and fast flings faster, or vice-versa, or generally adjust flings at different velocities in different ways. Attachment 8513736 [details] provides a graphical illustration of how this looks. See bug 1091049 comment 3 and bug 1091049 comment 14 for an explanation of how this works and suggestions for tuning using cubic-bezier.com. The set of prefs I would need for this are:

apz.fling_curve_function_x1
apz.fling_curve_function_y1
apz.fling_curve_function_x2
apz.fling_curve_function_y2

The above 4 define the bezier curve that maps the physical finger velocity to the visual fling velocity.

apz.fling_curve_threshold_inches_per_ms

This defines the lower velocity bound at which the fling curving takes effect.

apz.max_velocity_inches_per_ms

This defines the maximum fling velocity, and determines the upper bound of the bezier curve.
Flags: needinfo?(alam)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #3)
> So to give you a numerical example of how this works, say you have
> fling_accel_interval_ms set to 500ms, fling_accel_base_mult set to 1.5 and
> fling_accel_supplemental_mult set to 2.0. Then you start a fling at say 100
> pixels/second. 300ms later, the fling has slowed down to 50 pixels/second,
> and you do another fling with your finger moving at 75 pixels/second. Since
> 300ms < 500ms, this second fling will be accelerated using the formula given
> above:
> computed velocity = (new_fling_velocity * base_mult) + (old_velocity *
> supplemental_mult)
>  = (75 * 1.5) + (50 * 2.0)
>  = 212.5 pixels/second.

Sorry, I made an error here. The "old velocity" that is used is the initial velocity of the previous fling, rather than what it is at the time the second fling is done. So it would use 100 pixels/second instead of 50 pixels/second in the calculation:

(75 * 1.5) + (100 * 2.0)
= 312.5 pixels/second
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #3)
> So there's two sets of prefs that are relevant for tweaking this behaviour.
> The first is the "fling acceleration" set of prefs. "Fling acceleration" is
> when you do multiple flings in a row with your finger, and the velocity of
> the second fling onwards is accelerated beyond what you can do with your
> finger alone. The prefs that control this behaviour are:
> 
> apz.fling_accel_interval_ms
> 
> This is the time in milliseconds that determines whether a second fling will
> be treated as accelerated. If two flings are started within this interval,
> the second one will be accelerated. Setting an interval of 0 means that
> acceleration will be disabled.
> 
> apz.fling_accel_base_mult and apz.fling_accel_supplemental_mult
> 
> When applying an acceleration on a fling, the new computed velocity is
> (new_fling_velocity * base_mult) + (old_velocity * supplemental_mult). The
> base_mult and supplemental_mult multiplier values are controlled by these
> prefs. Note that "old_velocity" here is the initial velocity of the previous
> fling _after_ acceleration was applied to it (if applicable).
> 
> So to give you a numerical example of how this works, say you have
> fling_accel_interval_ms set to 500ms, fling_accel_base_mult set to 1.5 and
> fling_accel_supplemental_mult set to 2.0. Then you start a fling at say 100
> pixels/second. 300ms later, the fling has slowed down to 50 pixels/second,
> and you do another fling with your finger moving at 75 pixels/second. Since
> 300ms < 500ms, this second fling will be accelerated using the formula given
> above:
> computed velocity = (new_fling_velocity * base_mult) + (old_velocity *
> supplemental_mult)
>  = (75 * 1.5) + (50 * 2.0)
>  = 212.5 pixels/second.
> 
> So for the second fling, even though your finger was moving at 75
> pixels/second, it gets accelerated to 212.5 pixels/second. This behaviour is
> useful for the "get to the bottom of the page as fast as possible" use case
> where the user just flings like crazy.

What's this "window of opportunity" currently set at? 

It feels a bit less forgiving than I think it should be. When I compare with Chrome for example, it feels like I can wait a BIT longer than I can with Fennec and still qualify as a "quickly flinging to get to the bottom" gesture.

But apart from that, I think our current behaviour makes sense.

> The second set of prefs is for "fling curving". With fling curving, the
> fling speed is adjusted so that it isn't exactly what your finger was moving
> at. Instead, there is a function (a bezier curve) that maps the finger
> velocity to the "visual" velocity. This allows you make slow flings slower
> and fast flings faster, or vice-versa, or generally adjust flings at
> different velocities in different ways. Attachment 8513736 [details]
> provides a graphical illustration of how this looks. See bug 1091049 comment
> 3 and bug 1091049 comment 14 for an explanation of how this works and
> suggestions for tuning using cubic-bezier.com. The set of prefs I would need
> for this are:
> 
> apz.fling_curve_function_x1
> apz.fling_curve_function_y1
> apz.fling_curve_function_x2
> apz.fling_curve_function_y2
> 
> The above 4 define the bezier curve that maps the physical finger velocity
> to the visual fling velocity.
> 
> apz.fling_curve_threshold_inches_per_ms
> 
> This defines the lower velocity bound at which the fling curving takes
> effect.
> 
> apz.max_velocity_inches_per_ms
> 
> This defines the maximum fling velocity, and determines the upper bound of
> the bezier curve.

Sorry, I don't really follow what this fling curving does. But maybe there's nothing to do here either :) 

I think changing that "window" I mentioned above should make a noticeable difference.
Flags: needinfo?(alam) → needinfo?(bugmail.mozilla)
(In reply to Anthony Lam (:antlam) from comment #5)
> What's this "window of opportunity" currently set at? 
> 

500 milliseconds.
Flags: needinfo?(bugmail.mozilla) → needinfo?(alam)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #6) 
> 500 milliseconds.

Perhaps if we open this up a bit.

Can I try a fennec build with 750 ms? :)
Flags: needinfo?(alam) → needinfo?(bugmail.mozilla)
(In reply to Anthony Lam (:antlam) from comment #7)
> Can I try a fennec build with 750 ms? :)

You can try it on an existing build by going to about:config and changing apz.fling_accel_interval_ms to 750.
Flags: needinfo?(bugmail.mozilla)
Yup, what botond said.
Flags: needinfo?(alam)
ah! thanks!

I just tried it for a while and 750 does feel a LOT better. 1000 was too much.
Flags: needinfo?(alam) → needinfo?(bugmail.mozilla)
Created attachment 8707551 [details] [diff] [review]
Patch
Assignee: nobody → bugmail.mozilla
Flags: needinfo?(bugmail.mozilla)
Attachment #8707551 - Flags: review?(snorp)
Attachment #8707551 - Flags: review?(snorp) → review+
(In reply to Anthony Lam (:antlam) from comment #10)
> ah! thanks!
> 
> I just tried it for a while and 750 does feel a LOT better. 1000 was too
> much.

Personally, I find the current default is not suitable for me (physically). On my Nexus 6, having tested some large documents it takes more effort to achieve the same simple goal (e.g, to get to the bottom of a page) than Chrome (and Safari on iOS; especially coming from extended use of an iPhone).

For example, with http://thestar.com, on my Nexus 6, it takes about ~7 flings to get top to bottom of the site versus Chrome (~2 full flings with little friction). In Chrome, the page skates to the bottom, I personally like that and I can stop it at any time with a gesture.

Flipping `apz.fling_accel_interval_ms` from '750' to '1000' and even 2000, I find this much better for that fact that with fewer flings I can get to the bottom of the site quicker.

The current defaults on trunk seem like there's too much friction, and in general the scroll speed is slower than Chrome. There's less gliding/skating speed.

Comment 14

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/2b2ebbe0754d
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox46: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 46
You need to log in before you can comment on or make changes to this bug.