710119 - Short flings stop abruptly

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Patrick Walton (:pcwalton)]

As of the patches in bug 705092, when I do a short fling, the friction seems to not be applied at all before the page suddenly stops.

Comment 1

[Patrick Walton (:pcwalton)]

Attachment: Proposed patch.

So this kind of backs out that bug, but it seems to improve the look of short flings to me, without changing my ability to fling far (that I've noticed anyway).

Comment 2

[Chris Lord [:cwiiis]]

Comment on attachment 581171 [details] [diff] [review]
Proposed patch.

Review of attachment 581171 [details] [diff] [review]:
-----------------------------------------------------------------

I can't r+ this patch as it just brings back the bug that this change fixed (it's certainly very noticeable to me). I think lowering the friction factor and the stopped threshold will have a similar effect, without removing the feature of having faster flings decelerate slower. Preparing patch.

Comment 3

[Chris Lord [:cwiiis]]

Attachment: Lower friction factor and stopped threshold

Comment 4

[Patrick Walton (:pcwalton)]

Attachment: Proposed patch.

So actually this is mostly a bug in my code. STOPPED_THRESHOLD was never supposed to apply in the non-overscrolled fling case, but the overscroll revamp accidentally made it apply. This patch fixes it and now we coast nicely to a stop when flinging.

Comment 5

[Patrick Walton (:pcwalton)]

Wait, the formula for velocity is ((v^FF) * F)^(1/F), where v is velocity, F is friction, and FF is the friction factor. Isn't that just v^(F^(1/FF))?

Comment 6

[Patrick Walton (:pcwalton)]

Er, v*(F^(1/FF)).

Comment 7

[Patrick Walton (:pcwalton)]

Attachment: Proposed patch, version 3.

Here's another approach. The idea is really simple: it uses one friction factor for high velocity and another for low velocity. In my testing it seems to work pretty well: you want high friction for short flings so that your small pans don't cause too much motion while you're trying to read a long article or whatever, but low friction for long flings where you're dashing around a page. Note that iOS relies heavily on the "double-tap to return to the top of the page" feature, because it has relatively high friction all around, but Android users expect the friction to be low enough that they can just yank their way to the top of the page.

Comment 8

[Chris Lord [:cwiiis]]

(In reply to Patrick Walton (:pcwalton) from comment #5)
> Wait, the formula for velocity is ((v^FF) * F)^(1/F), where v is velocity, F
> is friction, and FF is the friction factor. Isn't that just v^(F^(1/FF))?

The formula is ((v^FF) * F)^(1/FF) (not 1/F), which doesn't simplify.

Comment 9

[Chris Lord [:cwiiis]]

Comment on attachment 581550 [details] [diff] [review]
Proposed patch, version 3.

Review of attachment 581550 [details] [diff] [review]:
-----------------------------------------------------------------

I fail to see how this would be favourable to having a friction factor? This just means there's going to be a weird jump in deceleration when velocity drops below VELOCITY_THRESHOLD. This could be modelled as a smooth curve using the factor code. VELOCITY_THRESHOLD might be a good idea to add as a constant into the factor equation though, to change it to;

nv = (v - k) + 1;
nv = ((nv^ff) * f)^(1/ff)
v = nv + (k - 1);

so that the friction applies at k velocity, instead of at 1 velocity.

Comment 10

[Patrick Walton (:pcwalton)]

(In reply to Chris Lord [:cwiiis] from comment #8)
> (In reply to Patrick Walton (:pcwalton) from comment #5)
> > Wait, the formula for velocity is ((v^FF) * F)^(1/F), where v is velocity, F
> > is friction, and FF is the friction factor. Isn't that just v^(F^(1/FF))?
> 
> The formula is ((v^FF) * F)^(1/FF) (not 1/F), which doesn't simplify.

Yes, it does: http://www.wolframalpha.com/input/?i=simplify+%28%28v^G%29+*+F%29^%281%2FG%29

The factor code that's in there now is equivalent to changing the friction, unless I'm missing something.

Comment 11

[Patrick Walton (:pcwalton)]

It really doesn't feel weird to me to have that jump. I couldn't notice it, and I like the simplicity of the approach.

Comment 12

[Patrick Walton (:pcwalton)]

Although I guess we could make it a little smoother by scaling once the velocity gets below a certain number, say 12. Would you be ok with that change?

e.g.:
if v < 12 then
    v *= (0.96 - 0.76) * (v / 12) + 0.76
else
    v *= 0.96

Comment 13

[Chris Lord [:cwiiis]]

My mistake, yes it simplifies, I've implemented it incorrectly :/ Your last suggestion is a good one, I'd be fine with that.

Comment 14

[Patrick Walton (:pcwalton)]

Attachment: Proposed patch, version 4.

Patch version 4 implements the suggested algorithm. It feels nice to me.

Comment 15

[Chris Lord [:cwiiis]]

Comment on attachment 581790 [details] [diff] [review]
Proposed patch, version 4.

Review of attachment 581790 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good :)

Comment 16

[Patrick Walton (:pcwalton)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/c8b8b310f27e

Comment 17

[Chris Lord [:cwiiis]]

http://hg.mozilla.org/mozilla-central/rev/c8b8b310f27e

Comment 18

[Catalin Suciu [:csuciu]]

Verified fixed on: 
Nightly 13.0a1(2012-03-04)
Device: Samsung Galaxy S2
OS: Android 2.3.4