Godot: Mouse Input Events called many times in between frames in 3.1

[kubecz3k]

Godot version:
3.1 Beta 8

OS/device including version:
GTX1060, Ubuntu 18.04

Issue description:
I encouraged this issue couple of times already in different projects, at a first glance it looks like the mouse input is a lot weaker in 3.1. After some investigation it turned out that Mouse Input Events are called many many times in between frames in 3.1 and this can lead to at least two problems:

1. Performance drop (if we have some logic in input function)
2. Feeling of a lot weaker input strength after porting project to 3.1 (when any of our logic that resides in process is based on the last input from mouse)

Steps to reproduce:
Quick way

1. Download sample project
2. Run it in 3.0, try to drag and drop sprite to the right edge of the window sceen
3. Run the project in 3.1, try to drag and drop sprite to the right edge of the window sceen
4. Notice that this is a lot harder in 3.1

Manual way

1. Open Godot 3.0
2. Create new scene, add a sprite as a child
3. Add this code to the scene root:

onready var sprite = get_node("Sprite")
var last_relative = Vector2()

func _input(event):
    if event is InputEventMouseMotion && (event.button_mask & BUTTON_MASK_LEFT):
        last_relative = event.relative

func _physics_process(delta):
    sprite.translate(last_relative)
       last_relative = Vector2()

1. Play a little, remember how it behaves
2. Open the same project in 3.1 and notice the difference

Minimal reproduction project:
weak_mouse_reproduction_3.0.zip

[kubecz3k]

ping @hpvb

[jonbonazza]

I've noticed this as well when dealing with UI input. I have had to work around it with hacky flags. Thought maybe it was my hardware, so I hadn't reported it, but if others are seeing it as well, it likely is engine related.

[moiman100]

I don't this is a bug. Event.relative is relative to the last event's position so
last_relative += event.relative
would work as long as it is zeroed after use.

[jonbonazza]

Perhaps I am thinking of something different. The issue I saw was specifically around mouse clicks. Eaxh click was firing multiple times for me. I just chalked it up to my laptop's touch pad. I havebt tried it on my desktop and I haven't tried since the 3.1 alphas.

[reduz]

This is most likely due to raw input generating way more events.
@kubecz3k I added motion event accumulation some days ago, you can try enabling it with Input.set_use_accumulated_input(true)
let me know if this fixes the problem. I am considering enabling it by default (it will only be a problem if you do something like painting using the mouse as it will lose some resolution).

[kubecz3k]

@reduz in current main (575f1d8ea4b1845ca4f52c61fbcfec8b1a9cee8d) the problem is a lot smaller. In Beta8 count of input readings between frames was ~= 10 and in current main it's around 2.
Enabling set_use_accumulated_input fixes the problem entirely and I also think it might be good idea to use it by default - I think some people (including me) is used to performing some logic inside _input, so it would be a waste of computing power when that logic is called many times between frames :)

[Calinou]

I am considering enabling it by default (it will only be a problem if you do something like painting using the mouse as it will lose some resolution).

This should be tested in first-person projects to make sure it doesn't increase mouse latency.

I think we should rather document this (along with ways to perform heavier processing in a real-time-friendly way).

[kubecz3k]

I created an issue after porting third person game (and tested in it as well), also as I said this is new behavior that was not present in 3.0

[reduz]

@Calinou no.. it should not matter for any type of game except for games that may need painting or very fine gestue recognition, which is not really common... guess will enable it.

The reason it's happening now is most likely due to raw input being implmented on Windows and X11.