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

If there is no movement, DragStart is not triggered. #17233

Merged
merged 2 commits into from
Jan 9, 2025

Conversation

rendaoer
Copy link
Contributor

@rendaoer rendaoer commented Jan 8, 2025

Objective

Fixed the issue where DragStart was triggered even when there was no movement
#17230

Solution

  • When position delta is zero, don't trigger DragStart events, DragStart is not triggered, so DragEnd is not triggered either. Everything is fine.

Testing

  • tested with the code from the issue

Migration Guide

Fix the missing part of Drag #16950

Copy link
Contributor

github-actions bot commented Jan 8, 2025

Welcome, new contributor!

Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨

@mnmaita mnmaita added C-Bug An unexpected or incorrect behavior D-Straightforward Simple bug fixes and API improvements, docs, test and examples S-Needs-Review Needs reviewer attention (from anyone!) to move forward A-Picking Pointing at and selecting objects of all sorts labels Jan 8, 2025
@NthTensor
Copy link
Contributor

NthTensor commented Jan 8, 2025

Startled that direct float equality works here, and that the previous pr didn't use an epsilon.

I need to review what's been happening here, but I we should probably just be ignoring movement events on the input side if they don't actually move.

@@ -668,6 +668,9 @@ pub fn pointer_events(

// Emit DragEntry and DragStart the first time we move while pressing an entity
for (press_target, (location, _, hit)) in state.pressing.iter() {
if delta == Vec2::ZERO {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why wouldn't this be done outside of the loop? delta doesn't change with each iteration.

Copy link
Contributor

@NthTensor NthTensor left a comment

Choose a reason for hiding this comment

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

IMO the check added by @mockersf in #16950 needs to be moved to line 664. Ether the pointer moves or it doesn't. This should be changing the semantics of the PointerAction::Moved event not which things we trigger.

@alice-i-cecile alice-i-cecile added S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged and removed S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Jan 8, 2025
@rendaoer
Copy link
Contributor Author

rendaoer commented Jan 9, 2025

If the delta of a move event is zero, subsequent events should be skipped.

@NthTensor
Copy link
Contributor

NthTensor commented Jan 9, 2025

Looking good, thanks. After further review, looks like the other check is a slightly different cross-frame delta. So this all looks correct now and what I said earlier about moving it was wrong.

It's still weird that we don't need an epsilon here, but I'll take it.

Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

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

I think that the "raw" inputs that we get from the OS / input devices are filtered to remove tiny perturbations, which is why we end up not needing an epsilon. I've watched the mouse input streams before and they're shockingly un-jittery.

@alice-i-cecile alice-i-cecile added S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it and removed S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged labels Jan 9, 2025
@rendaoer
Copy link
Contributor Author

rendaoer commented Jan 9, 2025

If it moves, Drag should be triggered again, so since it has been checked above, the check in Drag below should be unnecessary, right?

@rendaoer
Copy link
Contributor Author

rendaoer commented Jan 9, 2025

It doesn't seem to be a logical conclusion. Since it's correct, I won't bother with it anymore (sorry)

@alice-i-cecile alice-i-cecile added this pull request to the merge queue Jan 9, 2025
Merged via the queue into bevyengine:main with commit 7b56a1a Jan 9, 2025
57 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Picking Pointing at and selecting objects of all sorts C-Bug An unexpected or incorrect behavior D-Straightforward Simple bug fixes and API improvements, docs, test and examples S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants