"Input.use_accumulated_input = false" still accumulates inputs unless you spam the keyboard

[DexeloperGames]

Godot version

4.0-rc2, 4.0-rc1, 3.5.1

System information

Windows 10 (64-bit), Arch Linux 6.1.11-arch1-1 (x86_64)

Issue description

Input.use_accumulated_input always accumulates inputs regardless of setting on windows 10, unless you spam the keyboard with Input.use_accumulated_input = false

as seen here:

Input.use_accumulated_input = false + no keyboard spamming:

https://user-images.githubusercontent.com/124307450/219828447-52429cc3-d96b-4b66-a092-230715429b65.mp4

Input.use_accumulated_input = false + keyboard spamming:

https://user-images.githubusercontent.com/124307450/219828607-01b54d29-bcda-4b80-a3a9-b3015a24ad78.mp4

Input.use_accumulated_input = true does what's expected

Input.use_accumulated_input = true + no keyboard spamming:

https://user-images.githubusercontent.com/124307450/219828635-a94a99a9-8248-48eb-9415-62e51cf4f6c7.mp4

Input.use_accumulated_input = true + keyboard spamming:

https://user-images.githubusercontent.com/124307450/219828649-05cc471b-7012-45d0-ab2f-ab7467665a7c.mp4

this behavior also exists in 3.5.1 exactly the same

weirdly enough, it has to be specifically keyboard spam or mouse buttons (except scrolling) for it to work, atleast in my testing controller inputs don't influence the behavior

as a sanity check, i also asked a friend of mine to test this on arch linux (Godot 4.0-rc1), which showed completely different yet also somewhat buggy results

Input.use_accumulated_input = false + no keyboard spamming on arch linux:

https://user-images.githubusercontent.com/124307450/219828866-98446fac-2e56-4898-8dbb-a50f564b7716.mp4

Input.use_accumulated_input = false + keyboard spamming on arch linux:

https://user-images.githubusercontent.com/124307450/219828950-970fb5dd-8127-4372-bfe0-77ce734b0bf8.mp4

Input.use_accumulated_input = true + no keyboard spamming on arch linux:

https://user-images.githubusercontent.com/124307450/219829044-66b496cc-fb58-4b2c-a803-4c8a9bf85c79.mp4

Input.use_accumulated_input = true + keyboard spamming on arch linux:

https://user-images.githubusercontent.com/124307450/219829057-92973255-ca52-41cf-9294-8d855ba2948f.mp4

Arch Linux follows the intended behavior until you start spamming the keyboard with Input.use_accumulated_input = true

Steps to reproduce

in a new project, add a Node2D, and then add a Label as a child Add a script to the Node2D with the following:

extends Node2D

var cursor_input_positions : PackedVector2Array

func _ready():
    RenderingServer.connect("frame_post_draw",_frame_draw_post)
    Engine.max_fps = 1
    Input.use_accumulated_input = false

func _frame_draw_post():
    cursor_input_positions.clear()
    $Label.text = "Inputs this frame: "

func _process(delta):
    queue_redraw()

func _input(event):
    if event is InputEventMouseMotion:
        cursor_input_positions.append(event.position)
    $Label.text += "\n"+event.as_text()

func _draw():
    if cursor_input_positions.is_empty(): return
    for dot in cursor_input_positions:
        draw_circle(dot,3,Color.RED)
    if cursor_input_positions.size() > 1:
        draw_polyline(cursor_input_positions,Color.RED,6)

and then run the scene and move the cursor around

the intended behavior should be that, regardless of all other inputs, the cursor's trail should always and only be drawn if Input.use_accumulated_input = false, otherwise a dot should be drawn

Minimal reproduction project

Godot 4.0rc-2 Project input accumulation test gd4.zip

Godot 3.5.1 Project input accumulation test gd3.5.1.zip

[Sauermann]

I am unable to replicate this bug on Linux X11 Xfce, but can confirm it on Windows. I have looked into Input::parse_input_event and on Windows Input.use_accumulated_input = false is interpreted correctly in that function. So it looks like this problem originates in DisplayServerWindows.

Arch Linux follows the intended behavior until you start spamming the keyboard with Input.use_accumulated_input = true

This is expected behavior. Accumulation only happens on two consecutive Events, that allow accumulation. Basically after a InputEventMouseMotion, the next InputEventKey will reset the accumulation status. But between two Key-Events only a single MouseMotion-Event will be used and additional MouseMotion-Events between Key-Events will be discarded.

[Calinou]

I am unable to replicate this bug on Linux X11 Xfce, but can confirm it on Windows.

This seems to have been confirmed here: https://github.com/godotengine/godot/issues/36664