-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Significant input lag in editor since 3.2 #35719
Comments
@andy-noisyduck Which graphics card model are you using? |
@Calinou Intel UHD 620 (laptop). Apologies, updated report to include this. |
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. |
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: 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. |
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. I used Visual Studio's profiler for these results. Are these results usable? Or would you like me to use VerySleepy specifically? |
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. |
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). |
16GB on the device in question. I get the input lag with a new empty project. |
|
CSV of inclusive function calls attached. I've also included the same test using 3.1.2 for a comparison. Whilst trying to debug this, I have noticed some more oddities in 3.2 for me:
|
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. |
👍 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. |
That indeed fixes it. I guess that means it's the display not updating rather than input lag as initially thought. |
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... |
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 |
Updating to Intel drivers 26.20.100.7755 fixes the issue for me, thanks. I tested the other suggestions before updating. Using |
Thanks for answering 🙂 I'll close this issue as a duplicate of #23069 then. |
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.
The text was updated successfully, but these errors were encountered: