Closed Bug 1604330 Opened 5 years ago Closed 5 years ago

[Linux][GTK] Fling velocity doesn't match end velocity from apz.fling_curve_function_...

Categories

(Core :: Panning and Zooming, defect, P3)

Product:
Core
Component:
Panning and Zooming
Version:
73 Branch
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: sawyerbergeron, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0

Steps to reproduce:

  1. Enable/leave enabled apz.gtk.kinetic_scroll.enabled
  2. Adjust values for apz.fling_curve_function to create a bezier other than linear (default.) This is particularly observable with inputs
  3. Visit a long page and use fling at varying velocities

Actual results:

Resulting velocity curve is sharp/un-differentiable at point that action transitions from regular scrolling to fling animation. This displays itself as a visible jerk that makes the page feel like it's immediately stuck in mud, and makes fling feel significantly less "snappy"

Expected results:

Velocity at start of fling animation should match and smoothly transition down from the actual velocity at the end of a scroll gesture

Whoops, forgot to include: particularly noticeable with inputs (1, 0, 1, 0) for x1, y1, x2, y2 (extreme ease-in)

For some background on the "fling curve" prefs, see bug 1091049 and bug 1229841.

(In reply to Sawyer Bergeron from comment #0)

Velocity at start of fling animation should match and smoothly transition down from the actual velocity at the end of a scroll gesture

It's been a long time since I've looked at this, but based on the following from bug 1229841 comment 3:

[...] With fling curving, the fling speed is adjusted so that it isn't exactly what your finger was moving at. [...]

perhaps this is expected?

Perhaps it's being under-applied compared to what I'd expect? It's almost as though the curving is only applied during the pan movement, and stops being applied at fling animation start, this isn't observed for me on windows (at least that I can detect) so I figured it is probably an implementation difference since the GTK fling support was added.

The behavior from 1229841 is what I'd expect to happen, but doesn't seem to be happening

Trying to rule out placebo, maybe it's getting applied to fling but not to the actual pan part of the gesture? I think there's a few things I'm seeing that are probably not immediately related and may still be placebo.

Trying to figure out why things feel weird, I noticed there is no scrolling acceleration for me (same distance means same screen pan regardless of velocity) which is something edge has that seems to make edge feel subjectively "snappier". Based on this I'm assuming the fling_curve can't really change how the actual pan feels, so this bug may be filed in error (turning knobs that don't quite do what I thought they did.)

If that's the case it makes sense that "jerk" could be introduced by tuning the curve, though the mechanics for why it does what it does still somewhat confuse me.

Should I open a separate issue for a lack of pan acceleration or is that a wontfix/notabug?

I don't think fling curving is expected to accelerate the pan part of the gesture, only the fling part.

One thing to keep in mind, is that our fling logic (including fling curving) was designed for touchscreens, where the pan part of the gesture tracks your finger on the screen (i.e. if your finger goes down on top of a particular place in the content, we want it stay on top of that place), and that's something we don't want to change.

However, for a touchpad, the correspondence between positions on the touchpad and content on the screen is more tenuous, so accelerating the pan itself could be reasonable.

If you're interested in experimenting with this, I'm happy to point you to the relevant places in the code.

Priority: -- → P3

(In reply to Botond Ballo [:botond] from comment #5)

I don't think fling curving is expected to accelerate the pan part of the gesture, only the fling part.

That makes sense, was kind of confused about that from reading the comments for it

However, for a touchpad, the correspondence between positions on the touchpad and content on the screen is more tenuous, so accelerating the pan itself could be reasonable.

I seem to remember some analysis of this in https://pavelfatin.com/scrolling-with-pleasure/ and some related materials

If you're interested in experimenting with this, I'm happy to point you to the relevant places in the code.

Would love to take a crack at it :)

Cool! Here are some pointers:

  • This is the function where we handle touchpad pan events (on Linux, only in the apz.gtk.kinetic_scroll.enabled=true case) and have them trigger scrolling.
  • This line triggers the actual scrolling, with the amount scrolled determined by the startPoint and endPoint arguments.
  • The preceding parts of the function calculate how far to scroll based on the properties of the event. In particular, this if block is the one added by Greg in bug 1213601 to handle the sort of "page delta" events that we get on Linux and calculate a pixel scroll amount based on them.

So, if we want to accelerate pan gestures, this is the calculation we'll want to modify.

Additional notes:

  • The place where we currently apply the fling curve prefs is here, which is called from OnPan() (via here and here).
  • However, the mX.mVelocity and mY.mVelocity fields that this calculation updates, are not used for panning, they will only be used when the fling starts.

We'll need to figure out whether it makes sense to somehow factor the axis velocities into the pan calculation, or if we should separately apply the fling curving prefs for the purpose of panning. (Or, we could even do something like accelerate pans in a way that's independent of the fling curve prefs. The design space is somewhat open here.)

If we need to track additional state, we can add fields to Axis or AsyncPanZoomController as necessary, being careful to reset them in an appropriate place (like AsyncPanZoomController::OnPanEnd() or Axis::EndTouch()).

(I should mention, for general context, that an AsyncPanZoomController tracks scrolling and gesture related state for a single scrollable element, and Axis is a helper class to track quantities pertaining to a single axis of scrolling, with each AsyncPanZoomController having two Axis objects, mX and mY.)

Finally have a chance to look more into it, I see where I would add any transformation logic, but am not quite familiar with what kind of transformation would be the most "natural" feeling so I'll have to toy around with it a bit. I seem to remember some fitts law research that ended up arriving on a multiple-segment transformation but I may be misremembering

Threw together a quick exponential patch (just raises a pan delta to some power) which feels pretty good with ^1.3, seems to also be the type of profile used by OSX from what I can find. Still need to make it user configurable, maybe see if a linear segment for lower speeds improves things further.

Should I make a new bug report to track this since this one isn't really about scroll acceleration per-se?

(In reply to Sawyer Bergeron from comment #11)

Should I make a new bug report to track this since this one isn't really about scroll acceleration per-se?

Sure, please feel free!

Do you envision a different fix for this bug which builds on, or is independent of that one?

(In reply to Botond Ballo [:botond] from comment #12)

Do you envision a different fix for this bug which builds on, or is independent of that one?

As it stands, I don't think this bug is anything more than a misunderstanding of what some switches in about:config do, so is probably not actionable.

The real bug identified is the lack of scrolling acceleration being present, which would be the new bug, and carries on the changes I've been working on

Obsolesced by https://bugzilla.mozilla.org/show_bug.cgi?id=1605755

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.