| uid | input-system-event-processing |
|---|
Events are collected on a queue by the Unity runtime. This queue is regularly flushed out and the events on it processed. Events can be added to the queue manually by calling InputSystem.QueueEvent.
Each time input is processed, InputSystem.Update is called implicitly by the Unity runtime.
The interval at which this happens is determined by the Update Mode configured in the settings. By default, input is processed in each frame before MonoBehaviour.Update methods are called. If the setting is changed to process input in fixed updates, then this changes to input being processed each time before MonoBehaviour.FixedUpdate methods are called.
Normally, when input is processed, all outstanding input events on the queue will be consumed. There are two exceptions to this, however.
When using UpdateMode.ProcessEventsInFixedUpdate, the Input System attempts to associate events with the timeslice of the corresponding FixedUpdate. This is based on the timestamps of the events and a "best effort" at calculating the corresponding timeslice of the current FixedUpdated.
The other exception are BeforeRender updates. These updates are run after fixed or dynamic updates but before rendering and used used exclusively to update devices such as VR headsets that need the most up-to-date tracking data. Other input is not consumed from such updates and these updates are only enabled if such devices are actually present. BeforeRender updates are not considered separate frames as far as input is concerned.
Note
Manually calling InputSystem.Update is strongly advised against except within tests employing InputTestFixture or when explicitly setting the system to manual update mode.
Methods such as InputAction.WasPerformedThisFrame operate implicitly based on the InputSystem.Update cadence described above. Meaning, they refer to the state as it was in the last fixed, dynamic, or manual update happened.
You can query the current/last update type and count from InputState.