FPS drops when moving mouse with high polling rate

[AlexanderLangguth]

Godot version

3.4.2.stable.mono

System information

Windows 11, GLES3, NVIDIA GeForce GTX 1080 (511.65)

Issue description

Using mice with high polling rates creates massive FPS drops while moving the mouse.

The mouse used for testing has a polling rate of 1000 Hz. Moving the mouse drops the FPS from 120 down, even when nothing else is happening.
The faster the movements the harder the drop. For me it dropped from 165 FPS sometimes down to 50 FPS.
On another PC with a different mouse it dropped from 60 FPS down to 5 FPS during normal game-play.

When I change the polling rate of the mouse to 125 Hz the effect is still present, but way less noticeable.

Here are two graphs from the Godot profiler. The drops during mouse movement are clearly visible in both cases.
125 Hz mouse movement:

1000 Hz mouse movement:

The cursor also switches between our default cursor for the UI and the in-game cursor used to aim. This is somewhat visible in the attached video, although it is more noticeable in person.

2022-02-03.18-30-36.mp4

Steps to reproduce

Moving the mouse cursor with custom image around in a rapid way.

Minimal reproduction project

No response

[AlexanderLangguth]

In the video there are no FPS drops happening because I move the mouse slowly. Moving it quicker then drops the FPS. But I wanted to showcase the switching of the cursor.

[Calinou]

Can you reproduce this on Godot 3.3.4? If not, this is likely a duplicate of #55037. See also #54531 where a similar issue was reported.

Also, can you upload a minimal reproduction project? Running expensive code in _input() should be avoided to prevent performance drops of this kind.

[AlexanderLangguth]

Okay, I can confirm that the FPS issue disappears on Godot 3.3.4.
The FPS issue also disappears on Godot 3.4.2 when we set Godot.Input.SetUseAccumulatedInput(true);, so the default actually has changed, although the functions description say it is on by default.

So you can mark this issue as duplicate of #55037.

Running expensive code in _input() should be avoided to prevent performance drops of this kind.

Our _Input function actually does not do anything complicated.
For mouse movement it just checks if our Pawn is still a valid Godot object (not null and IsInstanceValid) and then sets the view direction (turns the arm)

public override void _Input(InputEvent @event)
{
    if (@event is InputEventMouseMotion)
    {
        if (this.Pawn == null || !IsInstanceValid(this.Pawn))
            return;
        this._viewDirection = this.Pawn.GetGlobalMousePosition() - this.Pawn.Position;
    }
    else if (@event is InputEventMouseButton mouseButton)
    {
        // sets attack state
        ...
    }
    else if (@event is InputEventKey keyEvent)
    {
        // handles movement
        ...
    }
}

When debugging we also noticed that the Godot Object Counter (Debugger -> Monitors) goes up with every mouse movement.
Without the input accumulation this actually jumps up multiple thousands for each mouse movement until then the GC kicks in and it drops down from 10k to 2k. With accumulation it happens way slower.
Maybe the engine could use object recycling for the input events to reduce the CPU and GC burden a bit?

We still have the issue that the cursor flickers between the two icons that we have.
It actually flickers in three different ways, but it's hard to capture this.
We have the pointer and the crosshair whose hotspot is moved a bit.

Input.SetCustomMouseCursor(ResourceLoader.Load("res://Core/Interface/Cursors/MainCursor.png"));
Input.SetCustomMouseCursor(ResourceLoader.Load("res://Core/Interface/Cursors/Crosshair.png"), Input.CursorShape.Cross, new Vector2(16, 16));

Although the crosshair is mainly displayed, as seen in the video, the pointer flickers through and the crosshair also sometimes flickers without the applied hotspot vector applied.

We will create another issue for this flickering and try to attach an example project, as this issue mainly focused on the FPS issue.

[Calinou]

Maybe the engine could use object recycling for the input events to reduce the CPU and GC burden a bit?

InputEvents in C# should be Dispose()d manually to avoid leaking memory. See #30821.

[akien-mga]

Maybe the engine could use object recycling for the input events to reduce the CPU and GC burden a bit?

InputEvents in C# should be Dispose()d manually to avoid leaking memory. See #30821.

It shouldn't leak memory, they are garbage collected. It just doesn't kick in early enough to match user expectations of an event's lifecycle.

[takhimi]

I just noticed this in Godot 4.0.3 rc1 . Empty 2D scene just with a label showing the FPS and it is running at fullscreen, My mouse polling rate(or report rate) is 1000 reports per seconds. The performance drops, from 5800fps(not moving the mouse) to around 4400fps(when moving the mouse erratically).

Should I make a new bug report ?

[Calinou]

I just noticed this in Godot 4.0.3 rc1 . Empty 2D scene just with a label showing the FPS and it is running at fullscreen, My mouse polling rate(or report rate) is 1000 reports per seconds. The performance drops, from 5800fps(not moving the mouse) to around 4400fps(when moving the mouse erratically).

Should I make a new bug report ?

Dropping from 5800 FPS to 4400 FPS is a 0.05 mspf frametime difference, which is insignificant. I think this is within expectations. The reduction you're seeing here is likely due to the OS having to update the mouse cursor position more often, not the engine.