You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
InputEvents.cs is where the keyboard/mouse events are attached to allow MonoGame to collect input.
If the mouse is moving/clicking then keyboard input is delayed until it stops. This includes key released states, so it effects first person game very badly.
Attaching to the CoreWindow's keyboard and mouse events shows this.
Attached to the CoreIndependentInputSource for the Mouse, with the keyboard coming from the CoreWindow (standard practice) also causes this.
This did not occur in Windows 8/8.1 and only occurs in Windows 10.
The text was updated successfully, but these errors were encountered:
Mouse events with CoreIndependentInputSource shouldn't block keyboard events in the main thread.
In any case can you test #5158? It removes the slow lock() which is significant in the case of Mouse where you have a rapid stream of events.
The other place I would look at is the Processing of Touch/Mouse Events. Perhaps that adds to the Draw time and cause the main thread to queue up keyboard events. In that case you have to move draw in it's own thread as well.
InputEvents.cs is where the keyboard/mouse events are attached to allow MonoGame to collect input.
If the mouse is moving/clicking then keyboard input is delayed until it stops. This includes key released states, so it effects first person game very badly.
Attaching to the CoreWindow's keyboard and mouse events shows this.
Attached to the CoreIndependentInputSource for the Mouse, with the keyboard coming from the CoreWindow (standard practice) also causes this.
This did not occur in Windows 8/8.1 and only occurs in Windows 10.
The text was updated successfully, but these errors were encountered: