705092 - Kinetic scrolling on web content is a bit too slow now

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect, P2)

Description

[Lucas Rocha (:lucasr)]

You now need several vertical flings to reach the bottom of the page. It would be nice if it was a bit faster. I guess we have to try several values to find the optimal scrolling speed? I know there are some performance implications there (i.e. we don't want to show checkerboard every time user scrolls) but I think we can do better.

Comment 1

[Wesley Johnston (:wesj)]

What we've got now is really just a deceleration constant. I think the trick here is low friction/deceleration when we're moving quickly, and strong friction/deceleration when we're slow (the exact opposite of what you'd do in a real world approximation). However, I don't think that's what we did before. For reference, our old xul "friction":

http://mxr.mozilla.org/mozilla-central/source/mobile/xul/chrome/content/input.js#884

Comment 3

[Chris Lord [:cwiiis]]

I'll take this.

Comment 4

[Patrick Walton (:pcwalton)]

According to android/widget/Scroller.java, Android is using true friction (defined through a complicated formula involving the gravity of the Earth -- no kidding!) that decreases velocity linearly. The native friction is scaled to the density of the device.

Looks like, from reading the code, that the formula is defined as (GRAVITY_EARTH * 39.37 * ppi * 0.015 / 2) pixels per second^2, where GRAVITY_EARTH is 9.80665 and ppi is 160 for a normal density device. So that's 463.306 pixels/s^2.

The friction that's currently implemented in PanZoomController.java isn't "real" friction (which is a force and imparts acceleration) but instead jerk [1] -- we decrease the velocity proportionally instead of linearly. (This is due to its Scrollability [2] heritage, which is generally considered to match iOS pretty well.)

I always felt that iOS friction felt more fluid than Android's, but this is one of those UX versus Android-native calls we have to make. UX should probably weigh in on this.

[1]: http://en.wikipedia.org/wiki/Jerk_%28physics%29
[2]: https://github.com/joehewitt/scrollability/blob/master/scrollability.js#L484

Comment 5

[Patrick Walton (:pcwalton)]

Friend who actually remembered his physics reminded me that GRAVITY_EARTH does make sense here, because it's the normal force. I still think it's pedantic for Android to express its friction constant in terms of that, but I stand corrected :)

Comment 6

[Chris Lord [:cwiiis]]

Is the android source you read current? There appears to be a big difference in the kinetic scrolling between ICS and Gingerbread, where ICS feels a lot like what we have now, except for the difference in applied friction. We probably want to match ICS, I agree that iOS feels better than gingerbread (though I would still suggest that being consistant with the platform is more important than a marginal improvement).

Comment 7

[Chris Lord [:cwiiis]]

Attachment: Introduce a friction factor

This patch introduces a friction factor, so that applied 'friction' is relative to current velocity. This lets you more easily fling through long pages. I've also slightly reduced the friction.

This feels better to me, but obviously exposes checkerboarding problems (which we should deal with in other bugs).

Comment 8

[Patrick Walton (:pcwalton)]

Comment on attachment 579685 [details] [diff] [review]
Introduce a friction factor

Awesome.

We are so far away from actual physical forces here, but I'm actually totally ok with that. I experimented with using real kinetic friction, but it doesn't feel as useful. When velocity is decreased linearly like real objects do, it either panned too short or too far. Apple was right here.

Comment 9

[Patrick Walton (:pcwalton)]

Wait... friction is actually the other way, so 0.75 will result in *more* friction. Was this intentional?

Comment 10

[Patrick Walton (:pcwalton)]

Comment on attachment 579685 [details] [diff] [review]
Introduce a friction factor

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

::: mobile/android/base/ui/PanZoomController.java
@@ +687,5 @@
>              if (disableSnap || FloatUtils.fuzzyEquals(excess, 0.0f)) {
> +                float absvelocity = (float)
> +                    Math.pow(Math.pow(velocity, FRICTION_FACTOR) * FRICTION,
> +                             1 / FRICTION_FACTOR);
> +                velocity = (velocity >= 0) ? absvelocity : -absvelocity;

Simpler: velocity = Math.copySign(absvelocity, velocity);

Comment 11

[Chris Lord [:cwiiis]]

Attachment: Introduce a friction factor (revised)

Revised patch based on review comments. I did not intend to increase the friction, was a silly mistake :) With that in mind, I've left the friction the same as it was originally and reduced the friction factor - this feels better to me.

We will probably want to tune these values at some point, along with all the other constants that control our throttling/update speeds, but this can be done in another bug if these values are good enough for now.

Comment 12

[Patrick Walton (:pcwalton)]

Comment on attachment 580937 [details] [diff] [review]
Introduce a friction factor (revised)

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

LGTM

Comment 13

[Chris Lord [:cwiiis]]

http://hg.mozilla.org/mozilla-central/rev/9989f0fed131

Comment 14

[Sam Tobin-Hochstadt [:samth]]

The scrolling speed is still much much slower in Native Fennec than in XUL Fennec or the Android stock browser.  This is particularly noticeable on extremely long web pages.  For example, in the stock browser, it takes about 3 flings to scroll through http://crookedtimber.org/2011/12/16/solidarity-2/ and probably 10 or 15 flings for Native Fennec.

Comment 15

[Patrick Walton (:pcwalton)]

(In reply to Sam Tobin-Hochstadt from comment #14)
> The scrolling speed is still much much slower in Native Fennec than in XUL
> Fennec or the Android stock browser.  This is particularly noticeable on
> extremely long web pages.  For example, in the stock browser, it takes about
> 3 flings to scroll through http://crookedtimber.org/2011/12/16/solidarity-2/
> and probably 10 or 15 flings for Native Fennec.

Could you file a new bug, since this one is marked fixed and it'll be easier to track that way?

Ultimately we do use a slightly different algorithm, so some sites will feel slower and some will feel faster. Also there's an Gingerbread-vs-ICS issue here, unfortunately.

Comment 16

[Brendan Eich [:brendan]]

Sam, please cite the new bug by number here. Thanks.

Do we need to scale things for long docs, so fewer flings are more effective?

/be

Comment 17

[Sam Tobin-Hochstadt [:samth]]

Reported as bug 716776.

Comment 18

[Chris Lord [:cwiiis]]

(In reply to Brendan Eich [:brendan] from comment #16)
> Sam, please cite the new bug by number here. Thanks.
> 
> Do we need to scale things for long docs, so fewer flings are more effective?
> 
> /be

Just to note, we already do this - perhaps the numbers need tweaking. It sounds like we need to get UX and dev in the same room and iterate over this.