Access Mouse Events between Updates()

Unity Engine
1

I’m trying to create a brush stroke system in Unity3D. As I found no way to access all the mouse data with the old Input Manager I gave the new InputSystem a go in Unity 2019.3. I read online things should now be framerate independent, but no matter what I try, reading the mouse position always seems to be limited by the Update() rate. Is there any way to access mouse deltas or positions as they are coming in from the native side? Even if I use the InputSystem.onEvent callback, the time resolution of the incoming events is not higher than the game’s framerate, it seems mouse events already get processed before onEvent. I do not need time accuracy, but I’d like to get all the mouse delta positions.

The problem is easily demonstrated by forcing the framerate in Unity to be 20 using Application.targetFrameRate and then adding points to a LineRenderer as they come in from the Mouse.

I have tried InputActions, onEvent, all the InputSystem update modes. Even manually calling InputSystem.Update() on a timer does not seem to help at all.

I read about time slicing and FixedUpdate() somewhere but it’s nowhere to be found.

2

Update: I wrote a test app to compare the old Input Manager, an InputAction and InputSystem.onEvent mouse input and it turns out things work fine on windows. However on Mac OS X, no additional information is available between Update() calls as described in the post before. So maybe it’s a problem with the native part of the System on Mac OS X? Anyway even on windows where I can use FixedUpdate to get more positions, it would be nice to somehow be able to access the raw mouse deltas with timestamps without any dependency on any update rate.

I will test the same thing on iOS and Android soonish and update this thread.

3

Ok things work fine with the FixedUpdate Input System updates on iOS, but indeed not at all on Mac OS X.

4

I really don’t understand what problem you’re trying to solve ?

FixedUpdate is probably just hiding the problem, because it still runs the same as Update, but on a fixed time. You could have more frame than “fixed frame”, but the other way around too.

If you use an action for mouse position, you will get “real time” events, but be extremely careful with that, when experimenting with the new input system I totally crashed both the Editor and my computer by accessing this (1000Hz mouse means 1000events will be triggered, absolutely don’t use expensive functions here as I did with Debug.Log)

5

The problem I’m seeing is that I don’t get the “1000Hz mouse events” on mac os x even when using an InputAction or EventSystem.onEvent. Something seems to limit the event rate to the Update() rate on OS X both in the editor and in .app builds. On windows I see the fast mouse events I’d like to have. Of course almost no processing should happen in those callbacks, but I want to collect us much information as possible in order to accurately trace the mouse/touch events in Update to get nice drawing behaviour. Are you seen 1000Hz events on Mac OS X?

6

btw. I also got crashes, but in my case it happened when I forgot to unregister callbacks…

7

I’ve never dealt with mobile yet. But 1000Hz is the polling rate of a mouse, it has nothing to do with mobile. Maybe it’s the OS / Driver / Whatever sends inputs in macOS that limit how much input it sends, and it could be not related to Unity or to the input system at all.

8

No, I know from developing on OS X natively that mouse input is dense. And I also see more events if I increase the Update() rate - that tells me they do exist. IMHO there is a problem in the OS X native side of the new InputSystem that combines events before they enter the managed part of the InputSystem. The native code is not on GitHub, so there’s no way to check this.

9

Well, then you’ll need to reach out @Rene-Damm , he can probably answer this

10

All mouse events from the system should come through as is. Collapsing should not occur at this point. Where it seems to happen, feel free to file a bug report. Could well be that on certain platforms, there’s some aggregation going on that I’m not aware of.

11

Thanks you for the reply. I tested on all the platforms I could (Windows, Android, iOS, Mac OS X) and the problem only occurs on Mac OS X. I don’t intend to release anything on that, so the problem doesn’t really affect me, but it just really confused me a lot as my main development machine is a MacBook Pro.

In a nutshell what I see is that on Mac OS X mouse events never reach the C# layer faster than the Update() rate.

I don’t have time to file a proper bug report right now - too busy, but maybe next week.