Migrated bug from GitHub: https://github.com/Unity-Technologies/InputSystem/issues/243

Sometimes an event takes longer to reach the OnUpdate code from the InputManager.
Is this an expected behavior?
For example in this case is took almost 2 frames at 60fps to start processing the event.

Code after this line:
https://github.com/Unity-Technologies/InputSystem/blob/develop/Packages/com.unity.inputsystem/InputSystem/InputManager.cs#L1960
var diff = InputRuntime.s_Instance.currentTime - currentEventTimeInternal;
if (!Application.isEditor) Debug.Log("[InputManager.OnUpdate] currentTime: " + InputRuntime.s_Instance.currentTime + ", currentEventTimeInternal: " + currentEventTimeInternal + ", diff: " + diff + ", currentEventType: " + currentEventType);

Output:
[InputManager.OnUpdate] currentTime: 27.9795653009787, currentEventTimeInternal: 27.9487711859848, diff: 0.0307900530304757, currentEventType: STAT

jonasmora commented on Sep 5
I increased the polling frequency to 120, with this the differences happen much less but still once in a while I get one greater than 1/60.

InputSystem.pollingFrequency = 120;

Rene-Damm commented on Sep 14 •
I believe we still have some problems coming down to parallel input. Input from background threads is set up such that it is never allowed to block the main thread from progressing.

My guess is that this is the source of lateness we've been seeing with touch on Android (where all input is coming from a background thread) and lateness of gamepad input on Windows (where HIDs and XInput devices are coming from a background thread). The polling thread probably runs into a situation with the background queue being full and then ends up getting starved for long enough to miss a frame. Not sure, however, that fits entirely with the picture of the problem decreasing when upping polling frequency.

Needs to be looked at.