-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
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
Fix routing of InputEventScreenDrag events to Control nodes #68632
Fix routing of InputEventScreenDrag events to Control nodes #68632
Conversation
CC @Sauermann |
I had a look at this PR and here are a few thoughts:
In order to make this work with Line 2473 in aa4c286
|
@Sauermann From a quick look at If we intend to support touch events (and multi-touch) in a viewport's subwindows, then it should be another PR since we wouldn't be fixing an existing behavior, but adding a new capability. |
89d538a
to
099d6f7
Compare
I see a possibility of dangling pointers to |
@RandomShaper Do you have reference for the picking logic I can look at? The current approach follows the pattern I've seen in the |
I mean usages like this: Line 668 in 0bb1e89
In that specific case, the relevant In this case of tracking which touch index is relevant to a specific control, I'd say that basing it on |
099d6f7
to
4e9c2ec
Compare
4e9c2ec
to
3ff7dd2
Compare
@RandomShaper I've updated the logic to use the |
Thanks! |
Multitouch support enables multiple concurrent
InputEventScreenTouch
andInputEventScreenDrag
events each differentiated by theirindex
property.An
InputEventScreenDrag
event typically follows anotherInputEventScreenDrag
orInputEventScreenTouch
event and thus should be routed to the target that last matched the previous touch event.Prior to this fix, in a multitouch scenario only the target of the first touch event was tracked, causing all subsequent multitouch drag events to be routed to that invalid target. The PR tracks the touch targets using the touch event's
index
property, and use that data to properly route drag events based on their matchingindex
property.3.x version
Bugsquad edit: