fix: mouse wheel responds on the first tick after a direction change - #21807
Merged
TurboGit merged 3 commits intoAug 14, 2026
Conversation
The discrete scroll accumulators (both the event controller proxy used by bauhaus sliders/dropdowns and dt_gui_get_scroll_unit_deltas) kept the signed fractional remainder from the previous scroll direction. After reversing direction, the first tick was silently spent cancelling that stale remainder, so it did nothing and a second tick was needed before the value changed. Drop the accumulated remainder when the incoming scroll delta changes sign, so the new direction takes effect on its very first tick.
1 task
Contributor
Author
|
Confirmed and fixed on Linux + Wayland, we should test under Windows to be sure. macOS I think it's fine as well |
Wheel notches arrive as GDK_SCROLL_SMOOTH events with |delta| == 1.0. The discrete proxy (bauhaus sliders, dropdowns and their popups) attenuated them by the 0.95 Linux/Windows scale, leaving a single notch at 0.95 -- below the 1.0 emit threshold of the accumulator. As a result the first notch of a scroll direction silently did nothing, and the fractional remainder it built up made the first tick after a direction change do nothing either. Dropping the remainder on a direction change (the previous commit) cannot help here: after the reset a single 0.95 notch still cannot cross the threshold. Keep the delta unattenuated in the discrete proxy so a notch is exactly one step; the smooth/touchpad proxy keeps the attenuation, and macOS keeps its compression on both paths since its scroll deltas are distance-based (several units per event).
TurboGit
reviewed
Aug 12, 2026
Restructure the #ifdef so only the conditional differs between platforms, making the shared attenuation code explicit.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Scrolling a bauhaus slider or dropdown with the mouse wheel was eating ticks: scroll a few notches up, then one down, and the first down notch did nothing — you had to scroll down twice to move the value. The very first notch of a scroll could get lost too (scroll three times, only two register). It affected sliders, dropdowns, and the alt/ctrl/shift zoom-range shortcuts.
Why
A wheel notch arrives at the scroll controller as a smooth event with delta ±1. The discrete scroll proxy was attenuating that to 0.95, and its accumulator only emits a step once it crosses ±1.0. So a single notch could never register by itself, and the leftover 0.95-ish remainder meant the first notch of the opposite direction was silently spent cancelling it. Released versions passed wheel notches straight through as exact ±1 steps, which is why this only showed up with the new proxy.
What changed
dt_gui_get_scroll_unit_deltas()(thumbtable, gradientslider, darkroom scroll-zoom, scroll shortcuts) gets the same direction-change handling.Single-direction scrolling behaves exactly as before.
Fixes #21390