Kinetic scrolling on web content is a bit too slow now

RESOLVED FIXED

Status

()

Firefox for Android
General
P2
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: lucasr, Assigned: cwiiis)

Tracking

unspecified
All
Android
Points:
---

Firefox Tracking Flags

(firefox11 fixed, fennec11+)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

6 years ago
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.
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
Duplicate of this bug: 705449
(Assignee)

Comment 3

6 years ago
I'll take this.
Assignee: nobody → chrislord.net
Priority: -- → P2
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
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 :)
(Assignee)

Comment 6

6 years ago
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).
(Assignee)

Comment 7

6 years ago
Created attachment 579685 [details] [diff] [review]
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).
Attachment #579685 - Flags: review?(pwalton)
Attachment #579685 - Flags: feedback?(lucasr.at.mozilla)
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.
Attachment #579685 - Flags: review?(pwalton) → review+
Wait... friction is actually the other way, so 0.75 will result in *more* friction. Was this intentional?
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);
(Assignee)

Comment 11

6 years ago
Created attachment 580937 [details] [diff] [review]
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.
Attachment #579685 - Attachment is obsolete: true
Attachment #579685 - Flags: feedback?(lucasr.at.mozilla)
Attachment #580937 - Flags: review?(pwalton)
Comment on attachment 580937 [details] [diff] [review]
Introduce a friction factor (revised)

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

LGTM
Attachment #580937 - Flags: review?(pwalton) → review+
(Assignee)

Comment 13

6 years ago
http://hg.mozilla.org/mozilla-central/rev/9989f0fed131
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
tracking-fennec: --- → 11+
status-firefox11: --- → fixed
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.
(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.
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
Reported as bug 716776.
(Assignee)

Comment 18

6 years ago
(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.
You need to log in before you can comment on or make changes to this bug.