Significant input delay ( Camera Lag )

[CrossVs]

Solution (for now):

Roblox users experiencing this issue can find tips and a solution here.

---

Description

During regular usage of the Roblox client with a ‘Gaming Mouse’; a user can build up significant client-side input delay. Hindering their ability to play reaction based games such as (but not limited to) First person shooters, Action games, Obbies, Minigames, etc…

It’s notable are that the client does not have to be ‘lagging’ or bottle-necked by hardware resources. I have recorded that the client can be running on any number just below 60 FPS (for example, 55 fps) with low CPU, GPU, and memory usage, and still build up over 5 seconds of input delay.

Describe ‘Input delay’

The amount of time it takes for a user’s action/input to make changes on the game client. Not to be confused with network latency (such as ping) or the player’s reaction speed.

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 takes action.

Guide to the issue

Edit:

The problem has been identified.
Find the cause and workaround solution here.

Setup (Edited):

• Set your mouse Polling rate to 1000hz
• Join a place that contains enough client-sided Lua heavy tasks (this one does it for my machine)
• Gain access to one or more of the following abilities to test your input lag with: walk, shoot, click, jump, interacting with UI, moving your camera, etc…

Steps:

1. Move your mouse around in a continuous uninterrupted pattern while keeping your fps below 60
2. Notice your inputs starting to increase in latency
3. Repeat step 1

Video displaying the issue:

Video A - Moving mouse

Video B - Stationary mouse - Compare with above

What happens in the video:

In the videos I am in a testing place with a fixed camera angle for each test. Directly looking at a difficult to render scene for the Roblox engine, causing me to be consistently below 60 FPS.
In this testing place there is a white frame in the bottom left corner that responds to UserInputService InputBegan events.
This frame will turn green at a random moment, and the user clicks when it appears green on their screen.
The moment the frame turns green, a timestamp is made to calculate how long it took for the user to send a UserInputService event.

Video A:

• The cursor is moving around
• Average input response time was over 8 seconds, increasing drastically over time

> 1013 1880 4526 17959 15430ms

Video B:

• The cursor is stationary and is not moved
• Average input response time was 289ms

> 263 267 288 276 280 259 296 288 276 296 296 292 359 309 313 263 301ms

Extra information:

• This issue occurred after a recent Roblox (or Windows) update
• The issue is 100% reproducible
• The issue started occurring in an update after 5th of August

Read important Footnotes:

• Any input is delayed, not just from UserInputService, but that’s what I have decided to use in this example.
• Even the Roblox Player responds late to things like alt tabbing back into the game.
• In this testing environment I can easily get over 8 seconds of input latency, but this is just to prove that there is a problem with the game client. In real scenarios this input latency would only be around 300-400ms at worst, but at random. Which in the case of action or rhythm games becomes really frustrating and unplayable.
• For players that do not have this over 8 seconds of input latency under the same conditions, they still seem to report that their input response time has increased by at least 70ms when their client no longer renders at 60 fps. Which should definitely also be improved upon.
• Even when I’m in a less graphically challenging game, and have my settings to the lowest, it is still possible for my client to stagger during quick rotations (flicks) of my camera angle. Causing the same input delay effect for a few frames as I am moving my mouse in this motion. But as mentioned before; this is increasingly frustrating as this affects action games a lot.
• Using the Roblox FPS Unlocker by axstin, and setting the FPS limit to 30 FPS does actually improve on the scene showed the video. No longer causing 8 or more seconds of input latency and only ending up around an average of ~360ms instead. ( Video: Imgur: The magic of the Internet ). My theory is that this input latency only queues up when the client is throttling frames. And with the FPS cap being at 30, it no longer throttles to run the scene. However, running at 30 FPS is no solution as this increases your input latency over 100ms by default.
• This input latency test includes the user’s time to respond (reaction time). Which on the average gamer should be around 230ms. You can calculate your own reaction time here, and subtract that average value from your results. This is nowhere close to scientific, but the results are clear enough that there is evidence of a problem. If you do have the hardware to scientifically calculate response time, I would love to see your results and compare them.
• This forum post might be related to the issue. The problem discussed is not well documented, so it is not clear if it is actually related. He posted this around the same time as when I first ran into this problem.

System info:

Home build desktop

Specs:

OS: Windows 10 Home
GPU: AMD Radeon RX Vega 56
CPU: AMD FX-8350 (8 Core 4200 Mhz)
Memory: 8GB Ram

misc & versions

OS version: latest - 1903
GPU version: latest - 19.8.2
CPU Cores/Threads: 8 / 8
CPU Clock: 4200 Mhz
CPU Platform: AM3r2
RAM Size: 2x Kingston 4GB
RAM Type: DDR3-1333 / PC3-10600 DDR3 SDRAM UDIMM
RAM Clock: 667 MHz

[CrossVs]

Aditional found information

While investigating even more on this issue, I’ve found that the Mouse Move timing under the Timings category is related to the input latency problem.
*(Ctrl + Shift + F1) in-game.

As I could not find any information on Mouse Move timer on the developer wiki, I can only speculate on it’s meaning and purpose. But I can lay down what it does:

What is the ‘Mouse Move’ timer?

When I as the user move my mouse around, this number increases to match my FPS. My speculation is that this is the update frequency of your mouse movement events in the game.

What I found

With this timer I can identify when the client is having input latency issues as this timer attempts to reach 0.0/s as soon as I stop moving my mouse. As demonstrated in the following video:

But when I test this during the input latency issue I get different results:

In the second video you will notice that the timer does not decrease fast at all and instead takes quite a while to finish. This duration matches very closely to the amount of time it takes for my input to be registered in the game client.

Speculation. This is actually speculation.

With this find I have more evidence that the client has input latency issues related to mouse movement.
My speculation is that when the client can no longer run at the targeted Framerate, it can no longer keep up with the amount of cursor inputs the client receives. And therefore start putting input tasks into a queue for the next frame to handle. Depending on how much the client is throttling, and how long you move the cursor, this queue can increase from microseconds to milliseconds, and even to seconds as demonstrated in the post.

Conclusion

This might be an issue I cannot solve in any way I try. This probably has to be looked into by the engineers.
If you’re having this issue right now, you can do the following to reduce the chance of this issue occurring:

1. Follow this guide on workaround solutions
2. You can lower the targeted frame rate of your client to 30FPS with the Roblox FPS unlocker to reduce the chance of game client throttle. But as mentioned in my footnotes, this is no solution as this increases input latency to a default 300ms. *Read the README before using FPS unlocker.
3. Wait for officials

[subcritical]

Can you attach a profiler dump?

Ctrl+F6 → Dump → 64 Frames, this saves an html file to C:\Users\username that you can post here or dm me

[CrossVs]

Thank you for replying,

Here’s the main profiler dump:

World_MovingMouse_microprofile-20190910-014800.html (4.9 MB)
This profiler dump was made during the most critical example of the latency issue.

I did run into one issue trying to make this dump that I believe is worth mentioning.
Because of my input being delayed by 8~17 seconds, it was tricky for me to create a correctly timed dump. To fix this, I have just been clicking my mouse roughly every second over the duration of 20 seconds and moved my mouse over the dump frames button to get a dump in the middle of the action.

---

Extra profiler dumps

For your convience, I have made a few extra. All in different conditions to compare with:

World_MovingMouse_microprofile-20190910-014800.html (4.9 MB)
World_StaticMouse_microprofile-20190910-005044.html (5.3 MB)
NoWorld_MovingMouse_microprofile-20190910-000946.html (3.1 MB)
NoWorld_StaticMousemicroprofile-20190910-001045.html (2.8 MB)

	World	No world
Moving mouse
Static mouse

Context

= Good/Short latency
= Acceptable latency
= Bad/Long latency

World = Compliated to render world
NoWorld = Spawnpoint and character
StaticMouse = Static non-moving mouse
MovingMouse = Moving my mouse around

[kingerman88]

This is an interesting issue which I as well experienced a few days ago.
While using the roblox linked sword, (I was roblox clanning) I found that there was a delay from when I (double clicked) to lunge until it actually lunged. There was a 1-3 second delay which was extremely annoying to fight with. I also noticed that my ping was abnormally high. Hope this can be fixed soon!

(Link to game)
https://www.roblox.com/games/2088996132/UCR-Gemini

[kingerman88]

Still experiencing this issue.

[CrossVs]

I have a feeling your issue is not related to this problem, and instead is an issue with ‘ping’. But I could be wrong!

Let me explain why I think this:

The client communicates with the server on when to perform linked sword actions via the Activated event on a server script. Causing the server to wait for client response, and then replicating the action back to the players and caster.
*Sample of Linked sword’s script
Depending on how high your ping might be, and considering you’ve mentioned that your ping is high during this problem. It is very likely that your issue is not related to what I described to be “Input delay”.

If ping is the problem you’re facing, a better description for your problem would be “Network lag”.

Describe ‘Network lag’

The latency of a “network” connection represents the amount of time required for data to travel between the sender and receiver. People perceive unexpected time delays as “lag”.

Describe ‘Input delay’

The amount of time it takes for a user’s action/input to make changes on the game client. Not to be confused with network latency (such as ping) or the player’s reaction speed.

[kingerman88]

Whoops, may have gotten ahead of myself

However it is odd that running at 200-300 ping causes the sword to have a second+ delay.
Sometimes it was responsive, other times not so much. Thanks for the help either way!

(cursor is client sided when I checked)

Inside the video, you can see that it takes a long while before the sword lunges.

EDIT I can add more video footage if wanted/needed. (I would need to sift through the hour and a half long video.)

[Den_S]

Got the same issue in my game. Some users with FPS lower than 60 get this exact issue. It looks like the UWA version of Roblox is not affected by this.

Got quite some other reports from players about actions they perform being inaccurate (e.g. actions are performed in a different location from where they actually clicked), which I suspect all being related to this too (but it’s hard to debug this with the average player). Players suggest to one another to reduce the Roblox graphics quality, which reduces/resolves issues for them.
I believe this issue causes a lot of confusion among those players.

[CrossVs]

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)

Extra info

https://i.imgur.com/rV6DltT.mp4

---

Sample 2: Hidden world, 150fps, Stationary mouse, No input delay
StationaryMouse-microprofile-20190916-140428.html (721.1 KB)

Extra info

https://i.imgur.com/9EwdzjN.mp4

---

Sample 3: Hidden world, 60fps(capped), Moving mouse, No input delay
MovingMouse-60fps-microprofile-20191008-211311.html (923.4 KB)

Extra info

https://i.imgur.com/S9ZOSxR.mp4

---

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.

[CrossVs]

Update

I’m not sure if any of the backend is working on this issue, but over the months I’ve noticed small but noticeable performance improvements in the input delay. And games such as Arsenal are now somewhat playable with a workaround:

The workaround

The workaround is to flick your mouse into stationary positions for the input queue to take breaks and catch up for the next move, or over-shoot in compensation for the consistent input delay. Setting graphics to 1 and capping FPS to 30 is necessary in some maps for the most optimal experience.
Although frustrating to have to play like this, it is playable

PC Specs:

OS: Windows 10 Home
GPU: AMD Radeon RX Vega 56
CPU: AMD FX-8350 (8 Core 4200 Mhz)
Memory: 8GB Ram

misc & versions

OS version: latest - 1903
GPU version: latest - 19.12.1
CPU Cores/Threads: 8 / 8
CPU Clock: 4200 Mhz
CPU Platform: AM3r2
RAM Size: 2x Kingston 4GB
RAM Type: DDR3-1333 / PC3-10600 DDR3 SDRAM UDIMM
RAM Clock: 667 MHz

The game client seems to struggle a lot less and recovers way faster from the input queue than before.

*Doing the same test from 70± days ago

That said, this issue with ‘Mouse Move’ will still hinder Roblox categories such as first person shooters and other action based games that involve mouse movement. This issue wasn’t apparent before an update around 2019-08-04T23:00:00Z on my machine

[Vmena]

This issue has been happening a lot recently. Moving my mouse in a roblox game, it is slow following my actual movement. When scripting in Roblox Studio, typing is slow and noticably delayed. I know many other people who are also experiencing this issue atm, so it’s not just my computer. My mouse/keyboard is functioning just fine in all other applications.

[JavascriptLibrary (Alex)]

I can also confirm this, I keep having the issue regularly on games that require a little bit more power

[JavascriptLibrary (Alex)]

I see the workaround working, but for FPS games, having a lower FPS gives a slight disadvantage. Though it does reduce input lag, it can still can cause a significant disadvantage.
The workaround will be ineffective on lower end machines if they are unable to reach 30fps in the first place.
@subcritical did comment on the thread a while ago but we have not since got an update on the situation so to me it appears like it’s just been ignored, forgotten about or chucked at the bottom of the pile of bugs to fix though I may be wrong. Hopefully it can be fixed at some point as it is irritating to watch your inputs still being done about five seconds later is quite frankly annoying.

[Vmena]

It’s gotten to the point where games are almost unplayable with the amount of delay sometimes reaching up to multiple seconds, this needs to be fixed.

[CrossVs]

@Vmena, @JavascriptLibrary,

Cause of the issue

I found out that having a 1000hz gaming mouse can be the cause of the engine inefficiency issue.
Lowering your mouse polling rate to 500 or 250 reduces the chance of your inputs being delayed by quite a lot.

The problem has mainly to do with our local machine and/or Roblox Lua not keeping up with the amount of updates our input device is sending to the engine.

If your game contains a lot of Lua heavy tasks, (which a lot of Roblox Action games do with their raycasting and lots of moving Roblox physics, and spawning Instances) it’s likely the reason why the input updates can’t keep up and cause the input queue effect.

What the user can do

Lower your mouse’s ‘polling rate’ to 250 or 500.
Windows does not have a way to lower your mouse polling rate. You will have to download your mouse company’s software and check for any available settings, or use a different mouse entirely.
Alternatively you can (and should) put your Roblox Client into ‘True Fullscreen’ mode (Alt+Enter) to severely reduce the amount of latency you can build up.

What the Developer can do

I recommend optimizing your game to reduce Lua heavy tasks such as:

Optimizing Physics
Optimizing Physics calculations by making object hitboxes less complex. Turn off CanCollide for complex objects (such as fine detailed Models or Unions/MeshParts) and replace it with a invisible ‘barrier’ brick.

Reduce spawning Instances
Reducing the amount of instances you spawn into workspace. Try to avoid rapidly destroying and re-parenting instances in and out of workspace. Instead try to re-use existing (hidden) instances, also referred to as “object pooling”.

These two tasks are the most CPU intensive from my testing, and when implemented correctly avoids building up large input queues.
However, even with these efforts you will likely still have a major(30-70ms) input latency as the source inefficiency can only be avoided by the user’s changing their mouse polling rate.

---

This is not a real solution.

Bottom line is that this is not something every user or developer can do.
Therefore I endorse the suggestion that this problem should be solved on Roblox their end.

[JavascriptLibrary (Alex)]

From your findings it appears like it is struggling to process data fast enough when polling rate is above 125HZ. So basicly being overloaded with data. Sadly some people do not have such settings available to them with their mouse so something still needs to be done on Roblox’s end

[CrossVs]

@JavascriptLibrary

Sadly some people do not have such settings available to them with their mouse so something still needs to be done on Roblox’s end

Very fair point.

Even with all the optimizations the developers can do, the user will likely still have 30~70ms input latency in the average servers due to the source of this inefficiency.

If the user cannot lower their Polling rate to a value low enough to match the engine’s capabilities, then there’s no solution to this issue.

Therefore I have untagged the “Solution” from this post.

[CrossVs]

New optimization

Thanks to @martinpvik for this find!
For anyone still watching this topic; putting your Roblox Client into ‘true Fullscreen’(Alt+Enter) will severely reduce the input latency from Martin’s and my testing.

Reducing your Polling rate to 250hz will still be the best solution, but in combination with a Fullscreen client you will not build up higher than ±320ms client latency.

I have updated the Cause of the Issue report with this information

---

Notice on Roblox’s fullscreen

There seems to be a difference between using Alt + Enter and F11 to go into ‘Full screen’.

The hotkey F11, or ‘Fullscreen’ option in the in-game settings might not be ‘true Fullscreen’, and instead be what most games call ‘Windowed Borderless Mode’ or ‘Borderless’ for short.
To gain a ‘true’ Windows based Fullscreen Roblox Client, you will need to use to shortcut Alt + Enter while in-game.

At the moment this is based on assumptions. However, It can be measured that Alt + Enter has more of a positive effect for your ‘Button To Pixel’ input latency than F11.

The benefit of Fullscreen versus Windowed Borderless has been studied and observed to have a measurable difference when it comes to Input Latency.

[CrossVs]

Release 447 has some good news

This change has significantly reduced input lag! (with a catch)

After some testing, I was quick to realize the problem isn’t entirely solved, especially for developers who use Scriptable camera type.

This only benefits the user under the following conditions:

• The Developer is using the default Custom CameraType
  + (and one of the following)
• The User is holding down Right Mouse Button
• The User is in First Person
• The User is making use of Shift Lock
• *Touch inputs untested

Note for developers:

This improvement only works with the Custom CameraType selected (ClassicCamera Module Script).
When the developer set the Camera to the Scriptable CameraType, this improvement in the camera input layer will no longer benefit the user.

I could not quite identify the reason behind the scenes to why this happens or how the improvement works from reading the CameraModule scripts, but it does look like they figured out a way to significantly improve the input queue issue as I was only able to build up to 800ms latency with the Custom CameraType.
Hopefully there is a way to get this improvement into our own camera scripts-