Fix routing of InputEventScreenDrag events to Control nodes

[m4gr3d]

Multitouch support enables multiple concurrent InputEventScreenTouch and InputEventScreenDrag events each differentiated by their index property.

An InputEventScreenDrag event typically follows another InputEventScreenDrag or InputEventScreenTouch 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 matching index property.

3.x version

Bugsquad edit:

• Fixes Control _gui_input inconsistent behavior with InputEventScreenTouch #29525

[akien-mga]

CC @Sauermann

[Sauermann]

I had a look at this PR and here are a few thoughts:

• The implementation seems to work for Controls in the root Viewport in my test-cases (I moved Controls around with event.relative) and the events are sent to the expected Control
• Same is valid for Controls in different SubViewports
• When a Control A is in the root Viewport and a different Control B is in an embedded Window, and both are dragged, then A doesn't receive InputEventScreenDrag events.
• Dragging or resizing an embedded Window has the effect, that no other Control or Window receives InputEventScreenDrag events, even if they were receiving these events previously.
• I didn't test TouchScreenButton

In order to make this work with Windows (not sure, how much of that should be supported), a necessary aspect would be to keep in each Viewport track, to which embedded Window each event should be sent in Viewport::_sub_windows_forward_input.

godot/scene/main/viewport.cpp

Line 2473 in aa4c286

bool Viewport::_sub_windows_forward_input(const Ref<InputEvent> &p_event) {

[m4gr3d]

I had a look at this PR and here are a few thoughts:

• The implementation seems to work for Controls in the root Viewport in my test-cases (I moved Controls around with event.relative) and the events are sent to the expected Control
• Same is valid for Controls in different SubViewports
• When a Control A is in the root Viewport and a different Control B is in an embedded Window, and both are dragged, then A doesn't receive InputEventScreenDrag events.
• Dragging or resizing an embedded Window has the effect, that no other Control or Window receives InputEventScreenDrag events, even if they were receiving these events previously.
• I didn't test TouchScreenButton

In order to make this work with Windows (not sure, how much of that should be supported), a necessary aspect would be to keep in each Viewport track, to which embedded Window each event should be sent in Viewport::_sub_windows_forward_input.

godot/scene/main/viewport.cpp

Line 2473 in aa4c286

bool Viewport::_sub_windows_forward_input(const Ref<InputEvent> &p_event) {

@Sauermann From a quick look at Viewport::_sub_windows_forward_input, it doesn't seem to support raw touch events (no reference to InputEventScreenTouch or InputEventScreenDrag), so this fix doesn't apply to it.

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.

[Sauermann]

Alternative to #49215
fixes #29525
Possibly related to #62597

[RandomShaper]

I see a possibility of dangling pointers to Controls in case they are deleted while they are still referenced. Maybe a simple fix is to store their ObjectID instead, similarly to what picking does.

[m4gr3d]

I see a possibility of dangling pointers to Controls in case they are deleted while they are still referenced. Maybe a simple fix is to store their ObjectID instead, similarly to what picking does.

@RandomShaper Do you have reference for the picking logic I can look at?

The current approach follows the pattern I've seen in the GUI struct where Control nodes are held by their pointers (example).

[RandomShaper]

I mean usages like this:

godot/scene/main/viewport.cpp

Line 668 in 0bb1e89

HashMap<ObjectID, uint64_t>::Iterator F = physics_2d_mouseover.find(res[i].collider_id);

In that specific case, the relevant Controls remove themselves from the list upon destruction. That said, it'd be interesting to know for sure if the other cases of use of raw pointers have safety guarantees because of some careful handling.

In this case of tracking which touch index is relevant to a specific control, I'd say that basing it on ObjectID is better than having to deal with some sort of callback mechanism to prune the map.

[m4gr3d]

@RandomShaper I've updated the logic to use the ObjectID instead.

[akien-mga]

Thanks!