Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When dragging to scroll, spurious drag velocity is applied #5174

Closed
valadaptive opened this issue Sep 27, 2024 · 0 comments · Fixed by #5175
Closed

When dragging to scroll, spurious drag velocity is applied #5174

valadaptive opened this issue Sep 27, 2024 · 0 comments · Fixed by #5175
Labels
bug Something is broken

Comments

@valadaptive
Copy link
Contributor

Describe the bug
When dragging to scroll in a ScrollArea, egui applies the drag velocity if the user releases their finger/mouse button mid-drag. However, this velocity is only updated when a drag actually takes place. If the cursor decelerates quickly, no drag events will be registered because it's not moving, and the velocity of the previous drag event will be used:

firefox_TBCANyJ9qf.mp4

To Reproduce
Steps to reproduce the behavior:

  1. Open the egui demo app
  2. Open a demo that lets you drag to scroll, e.g. the "Scroll a lot of lines" tab in the "Scrolling" demo, the "Misc Demos" window, or the "EasyMark Editor".
  3. Drag a scrollable area quickly, then decelerate your dragging movement rapidly.
  4. Release the mouse button and observe that the previous velocity is kept even if the cursor is currently not moving.

Expected behavior
No further scrolling should occur, as the cursor is completely still and hence has no velocity.

@valadaptive valadaptive added the bug Something is broken label Sep 27, 2024
valadaptive added a commit to valadaptive/egui that referenced this issue Sep 27, 2024
Fixes emilk#5174. The drag velocity was not being updated unless the cursor
counted as "dragging", which only happens when it's in motion. This
effectively guarantees that the drag velocity will never be zero, even
if the cursor is not moving, and results in spurious scroll velocity
being applied when the cursor is released. Instead, we update the
velocity only when the drag is stopped, which is when the kinetic
scrolling actually needs to begin.
@emilk emilk closed this as completed in ac2466d Oct 2, 2024
hacknus pushed a commit to hacknus/egui that referenced this issue Oct 30, 2024
Fixes emilk#5174.

The drag velocity was not being updated unless the cursor counted as
"dragging", which only happens when it's in motion. This effectively
guarantees that the drag velocity will never be zero, even if the cursor
is not moving, and results in spurious scroll velocity being applied
when the cursor is released.

Instead, we update the velocity only when the drag is stopped, which is
when the kinetic scrolling actually needs to begin. Note that we
immediately *apply* the scroll velocity on the same frame that we first
set it, to avoid a 1-frame gap where the scroll area doesn't move.

I believe that *not* setting `scroll_stuck_to_end` and `offset_target`
when the drag is released is the correct thing to do, as they should
apply immediately once the user stops dragging. Should we maybe clear
the drag velocity instead if `scroll_stuck_to_end` is true or
`offset_target` exists?

* Closes emilk#5174
* [x] I have followed the instructions in the PR template
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is broken
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant