Touchpad scrolling in Flickables is disproportionately faster than mouse wheel scrolling

[Daniel van Vugt]

Touchpad scrolling in dash and system settings is disproportionately faster than mouse wheel scrolling

I can only say this with confidence today because I implemented accurate smooth scrolling in Xmir yesterday, so I know how it should behave.

It's possible QtMir is overreacting to the large number of events that touchpads generate compared to a mouse wheel, without taking into account the scroll magnitude of each one is smaller.

[For mouse wheel problems please see bug 1556795 instead, although both bugs may be fixed together]

[Daniel van Vugt (vanvugt)]

Found the problem:

    void handleWheelEvent(ulong timestamp, QPoint angleDelta, Qt::KeyboardModifiers mods) override

QPoint is a pair of integers, but touchpad scroll values are floats.

[Daniel van Vugt (vanvugt)]

Bad news: The broken handleWheelEvent syntax is one we have inherited from QWindowSystemInterface so we can't just fix it in QtMir to use QPointF and libinput-style smooth scrolling :(

[Gerry Boland (gerboland)]

Are you looking at the right code? I see this from Qt5.4 source (qtbase/src/gui/kernel/qwindowsysteminterface.h)

    static void handleWheelEvent(QWindow *w, const QPointF & local, const QPointF & global, QPoint pixelDelta, QPoint angleDelta, Qt::KeyboardModifiers mods = Qt::NoModifier, Qt::ScrollPhase phase = Qt::ScrollUpdate);
    static void handleWheelEvent(QWindow *w, ulong timestamp, const QPointF & local, const QPointF & global, QPoint pixelDelta, QPoint angleDelta, Qt::KeyboardModifiers mods = Qt::NoModifier, Qt::ScrollPhase phase = Qt::ScrollUpdate);

Scroll units are floats. The line you're quoting is a QtMir internal thing, which we mistakenly used ints for.

[Gerry Boland (gerboland)]

Ah no, I'm reading the API wrong (kudos to faenil for correcting me):
QPoint pixelDelta
is in integers, as are all QWheelEvent calculations. So that's not going to work without breaking Qt APIs, which is unlikely.

An alternative option might be to us Qt's support for native gesture events - this is used on OS X. These do let Qt do Pan/Swipe gestures with float precision.

[Daniel van Vugt (vanvugt)]

That's an idea but we have a problem with libinput/Mir I think... It hides two-finger events from the client during a scroll, and only delivers vscroll events instead.

[Daniel van Vugt (vanvugt)]

Actually I think this bug might be tangential to the precision problem in QtMir.

QtMir appears to maintain a little smooth scrolling to a precision of roughly 0.067 mouse wheel ticks. But touchpads commonly have a precision of more like 0.00025 equivalent mouse wheel ticks.

So both problems are real. It's possible I have tied them together here in a single bug erroneously though.

[Daniel van Vugt (vanvugt)]

Come to think of it, the core of this bug might be outside of QtMir. That is whatever eventually receives handleWheelEvent is failing to scroll proportionately to the magnitude of angleDelta, and instead is scrolling just proportionately to the number of calls to handleWheelEvent.

[Daniel van Vugt (vanvugt)]

That's weird. The problem persists even in System Settings under Unity7. So not a bug in QtMir but more a bug in the toolkit layer (!?)

[Daniel van Vugt (vanvugt)]

Interestingly webbrowser-app under Unity7 behaves much better (same findings as bug 1523823).

So whatever the problem is in our QML app scrolling is not a problem in webbrowser-app.

[Daniel van Vugt (vanvugt)]

I've moved the general accuracy problem that's specific to Unity8 into bug 1607223.

This bug is all about certain apps only, and is reproducible in Untiy7.

[Andrea Bernabei (faenil)]

Doesn't webbrowser use Oxide to handle scrolling? I think it's not going through Qt's "Flickable".

It could be that it's a "generic Qt apps" behaviour problem.

Daniel, have you found any "pure" Qt app that behaves properly?

[Daniel van Vugt (vanvugt)]

I don't know any more "pure" Qt apps. Please suggest :)

[Andrea Bernabei (faenil)]

any core app aside from browser, I believe :)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

Seems like whatever is calculating the flick/fling velocity is to blame.

It feels like that code is incorrectly handling touchpad scroll events (which are much more numerous but lower magnitude than a wheel) as having a high flick velocity.

To avoid more confusion though, we might need to wait till bug 1607240 is resolved, and its many fixes landed.

[Daniel van Vugt (vanvugt)]

I found this is a general problem with 'Flickable' elements. And after speaking to Gerry about it last week confirmed the bug is in upstream Qt. Surprisingly the Flickable element only really works well with touch(screens).

[Daniel van Vugt (vanvugt)]

Worth mentioning Flickable's mouse wheel support is also pretty poor. If you move the wheel too quickly the Flickable may ignore the movement completely. If you move the wheel slowly that can make the scrolling go much faster.

Mouse wheels are relevant because it's the same code path as touchpad scrolling. High precision touchpad scrolling just emits smaller fractional values (float/QReal) of what would be a mouse wheel increment. And it works great everywhere except for Qt Flickable, which Unity8 uses a lot. :)

[Daniel van Vugt (vanvugt)]

And the problem persists in Unity7. If you run the System Settings app from Unity7 it has the same scrolling troubles.