Closed Bug 706615 Opened 8 years ago Closed 8 years ago

Panning motion slows, then jerks


(Firefox for Android :: General, defect, P1)




Tracking Status
firefox11 --- fixed
fennec 11+ ---


(Reporter: johnath, Assigned: cwiiis)




(2 files)

Our current panning code seems to have ease-out/deceleration physics where it comes to a rest as the panning action completes. However, rather than coming to rest, it decelerates towards zero, and then jumps to a final position a bit further along the panning path.

It seems like we'd want panning to smoothly come to a stop - the jerk at the end feels wrong.

Dupe? Phone-specific? (I'm on a galaxy s2, latest nightly)
I'm pretty sure this is due to some combination of Gecko being slow to paint, CPU contention between Gecko and the compositor, and texture upload. Taking this bug since it's basically what I've been working on for the past few days.
Assignee: nobody → pwalton
Actually, I think this specific bug is a regression that some of kats' work introduced. CC-ing him.
Assignee: pwalton → kgupta
The problem is changeset 4e745f151abd (bug 705114).
Yeah, this is a massive pain. If we can't rely on devices having sane touch events, I guess we should just use the system gesture detectors, which presumably have been tested by the manufacturer.
Attached patch WIP patch.Splinter Review
Here's a WIP patch. Should basically be a rebased version of your (Cwiiis') patch from earlier that switched to gesture detectors. This regresses clicking on links, so it can't land as is, but it should be the basic idea.
Assignee: kgupta → pwalton
Attachment #578182 - Flags: feedback?(
Comment on attachment 578182 [details] [diff] [review]
WIP patch.

Review of attachment 578182 [details] [diff] [review]:

Good other than what's noted below. I'd have thought that combined with wesj's patch in bug #704579 that just went in, this should solve that tapping links no longer works.

::: mobile/android/base/ui/
@@ +249,3 @@
>          if (mState == PanZoomState.PANNING_LOCKED) {
>              // check to see if we should break the axis lock
> +            double angle = Math.atan2(distanceY, distanceX);    // range [-pi, pi]

This is not equivalent to what was there before - distanceX,distanceY are the distances moved since the last call to onScroll, where this expects the distance moved since the first touch event.

@@ -454,5 @@
>              PLUS,       // Overscrolled in the positive direction
>              BOTH,       // Overscrolled in both directions (page is zoomed to smaller than screen)
>          }
> -        public float firstTouchPos;             /* Position of the first touch event on the current drag. */

We probably still want firstTouchPos for the comment above.
Attachment #578182 - Flags: feedback?( → feedback+
Duplicate of this bug: 706833
Priority: -- → P1
Taking this - will have a fix soon.
Assignee: pwalton →
This patch fixes the issue for me on my Galaxy Nexus.
Attachment #578333 - Flags: review?(kgupta)
Closed: 8 years ago
Resolution: --- → FIXED
Samsung Galaxy SII (Android 2.3.4)
OS: Mac OS X → Android
Hardware: x86 → ARM
tracking-fennec: --- → 11+
You need to log in before you can comment on or make changes to this bug.