Replace QScroller with custom KineticScroller. by poli0iq · Pull Request #327 · desktop-app/lib_ui

poli0iq · 2026-07-21T17:23:46Z

QScroller has:

A bad inertia curve (all of the default ones).
A bad initial acceleration estimation.

These can't be properly tuned, so the only option is to reimplement QScroller.

This implementation's maths is based on Chromium and GTK4.

This also replaces the screen refresh rate heuristics with proper frame scheduling (vsync-accurate).

KineticScroller also exposes velocity directly, allowing more precise overscroll behavior without relying on estimated velocity from rounded per-tick deltas (fixing the spring suppression in the slow fling tails).

ilya-fedin · 2026-07-21T19:11:48Z

+		if (OptionKineticScroller.value()) {
+			_scroller = new KineticScroller(this);
 		} else if (_scroller) {
-			QObject deleter;
-			_scroller->setParent(&deleter);
+			delete _scroller;


If we have access to constructor and destructor then use a smart pointer

Suggested change

if (OptionKineticScroller.value()) {

_scroller = new KineticScroller(this);

} else if (_scroller) {

QObject deleter;

_scroller->setParent(&deleter);

delete _scroller;

_scroller = OptionKineticScroller.value()

? std::make_unique<KineticScroller>(this);

: nullptr;

ilya-fedin · 2026-07-21T19:14:56Z

+						_wheelPos,
+						crl::now());
+				}
+				// The press event's own delta counts too: a short fling


So we're resurrecting ScrollBegin's delta here while ignoring it multiple lines above if we're in KineticScroller::Scrolling state?

These are different deltas. The one ignored above is the leaked macOS momentum stream (qnsview_mouse.mm can emit ScrollBegin straight from momentumPhase == Began when it misses the handoff), which we're already simulating ourselves.

On Wayland, though, ScrollBegin always has a zero delta, so it's the first ScrollUpdate that triggers the press, and its delta is a velocity sample we shouldn't drop.

How it happens ScrollUpdate triggers the press? ScrollBegin should trigger InputPress and the next ScrollUpdate triggers InputMove.

_wheelPos being null means no gesture is open. Normally ScrollBegin opens it with InputPress, then each ScrollUpdate sends InputMove. But the first event we see can be a ScrollUpdate, for example when the check above swallowed a real begin during a fling. In that case wasNull is true on the update, so the press comes from it. And unlike a begin, the update carries a real scroll delta, which we then send as the first InputMove: a short fling has only a few velocity samples, dropping one would noticeably weaken it.

But the first event we see can be a ScrollUpdate, for example when the check above swallowed a real begin during a fling.

You just said ScrollBegin always has zero delta on Wayland? If that's right, then this change has zero effect and should be reverted. If not, then remove the macOS workaround as macOS users aren't the expected users of this feature anyway.

Alright, I've debugged raw events and this path is indeed useless, the problem was related to Bluetooth buffering some events (leading to losing some short flings because we use crl::now() timestamps instead of QWheelEvent::timestamp()).

(yeah I use a bluetooth touchpad)

crl::now() was used only because QFlickGestureRecognizer uses QElapsedTimer so I mirrored it. If event timestamps are in fact better then we can use them.

ilya-fedin · 2026-07-21T19:16:36Z

+		if (OptionKineticScroller.value()) {
+			_scroller = new KineticScroller(this);
 		} else if (_scroller) {
-			QObject deleter;
-			_scroller->setParent(&deleter);
+			delete _scroller;
 		}


Smart pointer too.

Suggested change

if (OptionKineticScroller.value()) {

_scroller = new KineticScroller(this);

} else if (_scroller) {

QObject deleter;

_scroller->setParent(&deleter);

delete _scroller;

}

_scroller = OptionKineticScroller.value()

? std::make_unique<KineticScroller>(this);

: nullptr;

ilya-fedin · 2026-07-22T15:42:22Z

-			QObject deleter;
-			_scroller->setParent(&deleter);
-		}
-


could the empty line be returned?

ilya-fedin · 2026-07-22T15:42:46Z

-			QObject deleter;
-			_scroller->setParent(&deleter);
-		}
-


ilya-fedin · 2026-07-22T15:51:51Z

Last stylistic thing I see right now: both new .cpp and .h seem to use spaces rather than tabs.

And to technical things:

An annoying thing with QScroller is that it works in absolute coordinates, we have to convert deltas to absolute positions and back, just to then bug on loading more messages. Given that we change it, couldn't we get rid of this too and just directly operate on delta? Or is it crucial to the logic to know scroll area size and position?
If possible, I believe it would be nice to get rid of the handleWheelEvent/handleScrollEvent separation just like it was before QScroller introduction. We had to use scroll events with it, but we're not forced anymore with an in-tree API I believe.
Is there any sense to have separate ScrollerStopper now or would it be more effectively done by KineticScroller itself?

This reverts commit 1b34cf4.

QScroller has: 1. A bad inertia curve (all of the default ones). 2. A bad initial acceleration estimation. These can't be properly tuned, so the only option is to reimplement QScroller. This implementation's maths is based on Chromium and GTK4.

QScroller didn't expose it, so the only option was tracking the velocity from (rounded to integer) per-tick deltas, which read zero in the slow tail of a fling and suppressed the spring. The KineticScroller's velocity can be exposed and is exact at any instant, so use it instead.

Absolute positions came from QScroller. This was actually inconvenient, because we had to convert deltas to absolute positions and back, and rebase whenever loading messages moved the content.

The separation existed only for QScroller.

This only existed because QScroller couldn't watch mouse events itself. KineticScroller already event-filters its frame window, so stopping the fling on real pointer activity belongs to its Scrolling state.

poli0iq · 2026-07-24T10:12:00Z

Last stylistic thing I see right now: both new .cpp and .h seem to use spaces rather than tabs.

I don't think they do.

And to technical things:

An annoying thing with QScroller is that it works in absolute coordinates, we have to convert deltas to absolute positions and back, just to then bug on loading more messages. Given that we change it, couldn't we get rid of this too and just directly operate on delta? Or is it crucial to the logic to know scroll area size and position?

If possible, I believe it would be nice to get rid of the handleWheelEvent/handleScrollEvent separation just like it was before QScroller introduction. We had to use scroll events with it, but we're not forced anymore with an in-tree API I believe.

Is there any sense to have separate ScrollerStopper now or would it be more effectively done by KineticScroller itself?

All three implemented (as separate commits for now, lmk if I should fixup).

poli0iq mentioned this pull request Jul 21, 2026

Replace QScroller with KineticScroller telegramdesktop/tdesktop#31033

Draft

poli0iq force-pushed the kinetic-scroller branch from 4e67bb3 to c31e373 Compare July 21, 2026 18:35

ilya-fedin reviewed Jul 21, 2026

View reviewed changes

poli0iq force-pushed the kinetic-scroller branch 3 times, most recently from 4ee73c5 to a7ed8d7 Compare July 22, 2026 15:03

ilya-fedin reviewed Jul 22, 2026

View reviewed changes

Comment thread ui/widgets/elastic_scroll.cpp

QObject deleter;

_scroller->setParent(&deleter);

}

ilya-fedin Jul 22, 2026

Copy link
Copy Markdown

Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and here

poli0iq force-pushed the kinetic-scroller branch from a7ed8d7 to 72cac0f Compare July 23, 2026 20:48

poli0iq added 7 commits July 24, 2026 00:15

Revert "Work around QScroller::resendPrepareEvent bugs"

62ef0a5

This reverts commit 1b34cf4.

Replace QScroller with KineticScroller.

6c32880

QScroller has: 1. A bad inertia curve (all of the default ones). 2. A bad initial acceleration estimation. These can't be properly tuned, so the only option is to reimplement QScroller. This implementation's maths is based on Chromium and GTK4.

Use QWheelEvent timestamps instead of crl::now().

41cb171

Replace absolute positions with deltas in KineticScroller.

60442f7

Absolute positions came from QScroller. This was actually inconvenient, because we had to convert deltas to absolute positions and back, and rebase whenever loading messages moved the content.

Merge handleScrollEvent back into handleWheelEvent.

abc4857

The separation existed only for QScroller.

Fold ScrollerStopper into KineticScroller.

3ca8239

This only existed because QScroller couldn't watch mouse events itself. KineticScroller already event-filters its frame window, so stopping the fling on real pointer activity belongs to its Scrolling state.

poli0iq force-pushed the kinetic-scroller branch from 72cac0f to 3ca8239 Compare July 24, 2026 10:11

Uh oh!

Conversation

poli0iq commented Jul 21, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ilya-fedin commented Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

poli0iq commented Jul 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ilya-fedin commented Jul 22, 2026 •

edited

Loading