Significant input lag in editor since 3.2

[andy-noisyduck]

Godot version:
3.2 Stable (Mono)

OS/device including version:
Windows 10
Intel UHD 620 graphics

Issue description:
Tried out 3.2 today. I am getting severe input lag when interacting with the UI, sometimes up to 10 seconds, Menu highlights are out of position (presumably from the events for highlights being so far behind). Interacting with UI elements also has the same lag.

The delay itself seems to be quite variable, anywhere between 0.5s and 10s, but is always present. I am not sure if anything particular causes the longer delays. It seems to be random for me.

If I swap back to 3.1.2, there is no problem.

I am including video recordings to demonstrate.

I'm unsure how I can provide further information to diagnose this, but happy to do additional tests as needed.

[Calinou]

@andy-noisyduck Which graphics card model are you using?

[andy-noisyduck]

@Calinou Intel UHD 620 (laptop). Apologies, updated report to include this.

[lawnjelly]

Could do with profiling, e.g. with VerySleepy.

Although you might need a debug build with symbols to get more useful info. Do we have a build with symbols of 3.2 available? If not this might be quite useful for this kind of thing.

[lawnjelly]

Many thanks to @Calinou for making debug builds with program database which hopefully will allow users to profile / debug without installing all kinds of things to compile from source. If you are keen to help us track down this issue:

Download the 3.2 debug build from here:
https://github.com/Calinou/godot-debug-builds/releases

These debug builds are larger than the release builds (circa 2x the size), and are not optimized, but they containing extra debugging information to enable tools to find problems.

With the debug build you can now profile on your machine, so we can find out what is causing the slowdown. I have had success using the small profiling application VerySleepy in the past, and this is worth trying if you do not have another profiler installed.

A profiler allows you to run the editor / game but it takes timings as you do so, and will present a graph of which functions in the engine are using the most time.

[andy-noisyduck]

Attached is a short 30s profile interacting with the menus + about page. As before, there was significant input lag during the test. CPU is idle for almost all the test - it doesn't look CPU bound at all.

Profile.zip

I used Visual Studio's profiler for these results. Are these results usable? Or would you like me to use VerySleepy specifically?

[Zireael07]

How much RAM do you have? I am seeing something similar, but only in a moderately large 3D project while the game instance is running. I was suspecting the debugger thread, but it's not happening while a 2D project is running, so it's most likely not just the debugger, but also the amount of data involved.

[lawnjelly]

I used Visual Studio's profiler for these results. Are these results usable? Or would you like me to use VerySleepy specifically?

I personally don't have visual studio or a windows machine... Usually a screenshot of the profile chart is all that is needed, it will show up what is taking all the time (or a couple of screenshots ranking by which functions are taking the most themselves, and the most with themselves + child functions).

[andy-noisyduck]

How much RAM do you have? I am seeing something similar, but only in a moderately large 3D project while the game instance is running. I was suspecting the debugger thread, but it's not happening while a 2D project is running, so it's most likely not just the debugger, but also the amount of data involved.

16GB on the device in question. I get the input lag with a new empty project.

[andy-noisyduck]

I personally don't have visual studio or a windows machine... Usually a screenshot of the profile chart is all that is needed, it will show up what is taking all the time (or a couple of screenshots ranking by which functions are taking the most themselves, and the most with themselves + child functions).

[andy-noisyduck]

I am pretty suspicious of the 20% time spent in process_events, with a large amount if in spent parse_input_event. I don't know Godot's internals well enough, but they seem high?

[lawnjelly]

That provides some info, but really what we need is something like this (this is an example captured with valgrind):

A list of functions, with the percentage of time spent in each function.

From looking at the visual studio docs, it may be called 'functions view', (or maybe summary view, it isn't clear). If you think about it, we want to know which EXACT functions are using up lots of time. If you press a key or move a mouse, anything could be happening as a result of that (e.g. parsing the code etc).

Another useful bit of info is what percentage of time is within Godot and what within other processes (and what those processes are).

From the call tree so far nothing seems to be jumping out as the culprit though, it looks fairly normal, so I'm a bit stumped 😟 ... could be some kind of threading bug perhaps. Usually the culprit will jump out when profiling, if it doesn't, it is more difficult to investigate.

Also this is assuming you are using a brand new project for this and not altering the default settings. If you are using a pre-existing project maybe there is something in the settings causing it (multi-threaded rendering? anything like that?), and it would be worth providing a minimum reproduction project.

[andy-noisyduck]

CSV of inclusive function calls attached. I've also included the same test using 3.1.2 for a comparison.

FunctionSummary.zip

Whilst trying to debug this, I have noticed some more oddities in 3.2 for me:

• If I change the window size, the window will not redraw (it will be completely black) until an input event occurs (e.g. I move the mouse or click within the window).
• If I show the about dialog (Help -> About), the dialog will not show until I click on the editor window again. At this point the dialog flashes on screen, and then disappears again (presumably from the second click being away from the dialog).

[andy-noisyduck]

Putting these both here, as I think its all input related....

Video of the screen resize being black until a new event happens:

Video of the about window. Notice that after the menu is clicked, the screen does not update. If I move to the left of the screen, I will get the window resize cursor on the edge of the about window (where the window should be). If I move to the right, as soon as I hit the scrollbar on the about window, a redraw seems to happen and I get the window as expected.

[lawnjelly]

👍 That does suggest the possibility that the real problem is that rendering the screen on demand isn't working correctly. It is even possible that the 'lag' is not real lag at all, but godot not realising that the frame has not been displayed. That would explain why there is nothing obvious in the profile.

Of course I can't say this with any certainty, only you know the behaviour. You could try setting the IDE update mode (with the spinner) to continuous and see what effect this has. I'm presuming you have it set to 'update when changed'. If not, then something very strange is going on with your screen updates.

[andy-noisyduck]

You could try setting the IDE update mode (with the spinner) to continuous and see what effect this has.

That indeed fixes it. I guess that means it's the display not updating rather than input lag as initially thought.

[lawnjelly]

Could be something in the windows OS / SwapBuffers code, I don't really know that side so I'll bow out now. There were recently some changes adding vsync via compositor, could possibly be something to do with that. I've had similar problems in the past using glAddSwapHintRectWIN function on some devices.

Or it could be graphics drivers, although I don't usually like to try and blame third parties .. and you'd have thought you'd see similar problems in other programs...

[Calinou]

Now that I read it again, this issue reminds me a lot of #23069. Try updating your graphics driver to the latest version provided by Intel. Alternatively, start the Godot editor with the --verbose command-line argument, which can also mitigate the issue.

[andy-noisyduck]

Updating to Intel drivers 26.20.100.7755 fixes the issue for me, thanks.

I tested the other suggestions before updating. Using --verbose made no difference for me. Interestingly, it wasn't actually the "Update Continuously" setting that also fixed it, but rather the "Show Update Spinner" setting alone (ie. with "Update Continuously" still off). For some reason the presence of the spinner resulted in the screen updating correctly. I was unable to tell this was a regression or not, since I can't disable the spinner in 3.1.2 - the option doesn't do anything for me when toggled. The problem could have always been with on the older drivers and just hidden by having the setting always on.

[Calinou]

Thanks for answering 🙂 I'll close this issue as a duplicate of #23069 then.