turns out I’m not the only one with this issue, so I’ll gladly provide more information
More & New information:
During further testing and looking into this issue, there has been a few new discoveries that might help resolve or identify the problem.
Video showing the input delay in-game
I guess I haven’t shown what the input delay might look like in-game yet, but it’s quite hard to visualize. So here’s a video of me moving my mouse in a continues circular motion, but getting slowed down and throttled by the input delay problem.
At the end of the clip you can see all my build up inputs all firing tick by tick ‘catching up’ to real time input.
Describe the behavior
The client starts putting input tasks (such as UserInputService events) from the user into a ‘queue’, that can end up to around 400ms or higher before the input is registered as an event.
Releasing your mouse will make this queue rapidly fire the events in a sequence to ‘catch up’.
Setting processor affinity
*Taskmanager’s ‘Processor affinity’ window
After some testing, we found that setting the processor affinity for RobloxPlayerBeta.exe to only use physical cores of your CPU reduces how long it takes for the input latency to recover during the ‘catching up’ period. This makes the playing experience slightly better when I combine this with setting my graphics to the lowest level, but this is no solution.
Another interesting find
I am not sure quite how relevant this find is to figuring out the solution as I will describe soon, but I can obtain the same input latency issue while being way over 60fps
In my testing place that I’ve primarily used to replicate this issue, I have made debugging tool that can be used to test environment changes and camera conditions.
| Despawn world | Re-parents the world into nil, making it no longer render |
| Hide world | Changes all the properties of visual objects to make it invisible, hiding it from view |
| Toggle auto camera | Turns the camera into Scriptable and moves it around automatically |
| Toggle CoreGui | Hides all the allowed CoreGui elements via SetCoreGuiEnabled method |
*Debugger GUI
If I hide the world from view via the Hide world button, enable Auto camera, and load up Rbx FPS unlocker with the no limit option. I can replicate the same fps issue while having over 120fps.
This could be a side effect from using the FPS unlocker tool. But speculating that it isn’t, this could be another clue for the engineers to take a guess on where this issue might originate. (maybe another clue that the issue is FPS throttling, or still related to mouse movement)
Note:
This does not happen when you use Despawn world over Hide world.
Only differences I found over the two is ±150fps, and Hide world still processes the rendering queue for all the invisible and disabled objects.
Profiler on Hidden world setting
Another nice side effect from this is that the profiler data has become very minimal and easier to read while still containing the problem (if the problem is even visible in the profiler that is)
*MicroProfiler
Sample 1: Hidden world, 120fps, Moving mouse, High Input delay
MovingMouse-microprofile-20190916-140339.html (830.6 KB)
Sample 2: Hidden world, 150fps, Stationary mouse, No input delay
StationaryMouse-microprofile-20190916-140428.html (721.1 KB)
Sample 3: Hidden world, 60fps(capped), Moving mouse, No input delay
MovingMouse-60fps-microprofile-20191008-211311.html (923.4 KB)
A few other profiler samples can be found in a previous post above
Another interesting thing to note here is that Sample 1&2 above are in the same setup and scene, but differ in ~30fps purely from just moving my mouse around.
