godot
godot copied to clipboard
godotengine
Godot 4 editor UI (menus) significantly slower then 3.x
Godot version
4.0.beta7 - 4.0.beta14
System information
Windows 8 x64, Radeon RX 5500 XT (8Gb), 16 Gb RAM
Issue description
Editor UI is much slower then in 3.5. Best example is mouse moving over menu - there is a visible lag between mouse movement and menu items highlighted. No such problem in 3.5.x. I tried beta builds 7, 9, 10, 11, 12 and 14. I remember alpha has similar performance as well. Here is a short video comparison (11 seconds): https://youtu.be/3WGXcd-TUyg
Steps to reproduce
Open any menu and move mouse up-down over items. Other variant: open project settings or editor settings and drag scrollbar up and down (less noticeable though).
Godot 3.5 editor is very responsive comparing to Godot 4 betas.
Minimal reproduction project
N/A
Hmm I can't reproduce that menu hover slowness personally - Windows 10, Ryzen 3600 GTX 1080
I see reduced responsiveness of most of the editor, including run/stop buttons and remote scene tree, compared to 3.5.
Linux Manjaro, Intel Kaby Lake
Related to https://github.com/godotengine/godot/issues/70869.
- Can you reproduce this after switching to the 2D tab? If 3D rendering is slow in the current scene, 2D rendering in the editor will also be affected.
- Can you reproduce this after switching to the Forward Mobile rendering method in the advanced project settings, then the Compatibility method?
- Can you reproduce this after forcing the high performance profile in your graphics driver's control panel (e.g. Prefer Maximum Performance on NVIDIA)?
Vulkan backends (Forward Plus/Mobile) currently lack 2D batching, which make rendering the editor slow. This is especially noticeable on slower GPUs, or those with aggressive power scaling (i.e. AMD GPUs unless they're forced to a high power state in the driver settings). Implementing 2D batching is planned for a future 4.x release, possibly with MultiRect.
In contrast, the Compatibility (OpenGL) method uses a form of 2D batching (it's different from the one in 3.x, but achieves the same goal).
Benchmark
OS: Fedora 37 KDE (compositing disabled) CPU: Intel Core i9-13900K GPU: GeForce RTX 4090 (NVIDIA 525.60.11) Resolution: Fullscreen editor on 3840×2160 display
Benchmark instructions (3.x)
- Create a new project.
- Enable Update Continuously and Show Update Spinner in the Editor Settings.
- To reflect 4.0's preview sun system: Add a Node3D with a WorldEnvironment child. Add an Environment resource with a default ProceduralSky.
- To reflect 4.0's preview sky system: Add a DirectionalLight node and enable shadows for it.
- Disable Use V-Sync in the Project Settings. Use the Save and Restart button to ensure this change is persisted, and check the project settings again just in case.
- Quit and run the editor with the following CLI arguments:
godot /tmp/4/project.godot --print-fps - Open 2D tab, wait 6-8 seconds.
- Open 3D tab, wait 6-8 seconds.
- In 3D tab, remove the WorldEnvironment and DirectionalLight nodes, then wait 6-8 seconds.
- Open script tab, wait 6-8 seconds.
- Quit the editor, look at the printed FPS output in the console. Split the values when you notice a clear difference in FPS count, then perform an average of the values for each tab (with two averages for 3D: one with sun/environment, one without).
Benchmark instructions (4.0)
- Create a new project.
- Enable Update Continuously and Show Update Spinner in the Editor Settings.
- Quit and run the editor with the following CLI arguments:
godot /tmp/4/project.godot --print-fps --disable-vsync - Open 2D tab, wait 6-8 seconds.
- Open 3D tab, wait 6-8 seconds.
- In 3D tab, click the sun and globe icon at the top of the 3D editor viewport, then wait 6-8 seconds.
- Open script tab, wait 6-8 seconds.
- Quit the editor, look at the printed FPS output in the console. Split the values when you notice a clear difference in FPS count, then perform an average of the values for each tab (with two averages for 3D: one with sun/environment, one without).
3.5.1 (GLES3)
- 2D tab: 3138 FPS
- 3D tab: 1922 FPS
- 3D tab (no sun/environment): 2440 FPS
- Script tab (no script open): 5628 FPS
3.5.1 (GLES2)
- 2D tab: 3395 FPS
- 3D tab: 3619 FPS
- 3D tab (no sun/environment): 4023 FPS
- Script tab (no script open): 5231 FPS
4.0.beta13 (Forward Plus)
- 2D tab: 3815 FPS
- 3D tab: 1638 FPS
- 3D tab (no sun/environment): 2440 FPS
- Script tab (no script open): 5628 FPS
4.0.beta13 (Forward Mobile)
- 2D tab: 3797 FPS
- 3D tab: 2315 FPS
- 3D tab (no sun/environment): 3287 FPS
- Script tab (no script open): 5598 FPS
4.0.beta13 (Compatibility)
Can't benchmark, as V-Sync currently can't be disabled with the Compatibility rendering method.
I always switch to script tab upon launching the project, so that there is no double-rendering. Doesn't help at all, neither with the stop/start nor remote tree.
I always switch to script tab upon launching the project, so that there is no double-rendering.
I'm referring to editor rendering itself, not running a project while the editor is running in the background.
Doesn't help at all, neither with the stop/start nor remote tree.
What "doesn't help at all"? Are you referring to switching to the Compatibility rendering method?
No, I was referring to switching to script tab. (I don't think I can use Compatibility rendering as I use things not implemented in GLES to my knowledge, e.g. shader instance uniforms)
Here are 120 FPS videos when moving the mouse on PopupMenus. Try pausing the video while the cursor is moving fast in those videos, and notice how far apart the cursor is from the highlighted option. On videos with editor V-Sync disabled, you'll notice the mouse cursor is a lot closer to the highlighted option.
3.5.1
GLES3 V-Sync enabled
https://user-images.githubusercontent.com/180032/213909749-b32cddca-a986-4cf9-9ac7-afe1bfd978e2.mp4
GLES3 V-Sync disabled
https://user-images.githubusercontent.com/180032/213909746-67cd21af-ee32-4ad2-8be5-047346da370d.mp4
4.0.beta13
Forward Plus V-Sync enabled
https://user-images.githubusercontent.com/180032/213909752-439b314e-4372-425a-915b-cd225b1f0351.mp4
Forward Plus V-Sync disabled
https://user-images.githubusercontent.com/180032/213909751-676f9be8-0c0f-4a1d-891a-6aadebd63d57.mp4
Compatibility V-Sync enabled
https://user-images.githubusercontent.com/180032/213909750-98dadaa9-aa0d-4165-ab3d-86e660597a85.mp4
Compatibility V-Sync disabled
Can't record, as V-Sync currently can't be disabled with the Compatibility rendering method.
In conclusion: V-Sync contributes a lot to input lag within the editor. Disabling it mostly resolves the issue, bringing input lag down to one rendered frame (we probably can't do better unless we extrapolate the cursor's position – an interesting, but error-prone idea).
https://github.com/godotengine/godot/pull/48364 could help a lot here, possibly while also disabling V-Sync by default in the editor. (I know this causes tearing, but tearing is generally not common when working within the editor, as scrolling is usually vertical as opposed to horizontal.)
Thank you for reply, Calinou.
- Can you reproduce this after switching to the 2D tab? If 3D rendering is slow in the current scene, 2D rendering in the editor will also be affected.
Same problem in any tab: 3D, 2D and Script. Also it is not a complex scene, same problem in all tabs with [empty] scene.
- Can you reproduce this after switching to the Forward Mobile rendering method in the advanced project settings, then the Compatibility method?
No problem in Compatibility mode! But same problem both in Forward+ and Forward Mobile.
- Can you reproduce this after forcing the high performance profile in your graphics driver's control panel (e.g. Prefer Maximum Performance on NVIDIA)?
Unfortunately I cannot try this because AMD app that configure this not runs on Win8.
My results for benchmark are somehow strange:
Godot 3.5.1 and 3.5.2-rc2:
Godot Engine v3.5.1.stable.official.6fed1ffa3 - https://godotengine.org Requested V-Sync mode: Disabled OpenGL ES 3.0 Renderer: Radeon RX 5500 XT Async. shader compilation: OFF
Godot Engine v3.5.2.rc2.official.1a2bf3eb4 - https://godotengine.org Requested V-Sync mode: Disabled OpenGL ES 3.0 Renderer: Radeon RX 5500 XT Async. shader compilation: OFF
Results: almost exact 60 FPS regardless of selected tab, both GLES2 and GLES3 (double checked that vsync option disabled).
Godot 4 beta 14:
Godot Engine v4.0.beta14.official.28a24639c - https://godotengine.org Vulkan API 1.2.170 - Using Vulkan Device #0: AMD - Radeon RX 5500 XT Requested V-Sync mode: Disabled
Forward+: FPS randomly changes between 750 - 850 on 2D, 3D and 3D without light/env, script tab 1000-1100. Forward Mobile: mostly same, but script 920-960. Compatible mode: most time 60 FPS exact, except 3D with light/env which is almost exactly 30 FPS.
And one more test: Forward+, script tab, menu opened: while idle around 1100 FPS, but when I start moving mouse up-down in menu - FPS drops to 30-80 (changes randomly), then returns to 1100 when mouse idle again.
For submenus, this is related: https://github.com/godotengine/godot/issues/70361
But in general, I feel that the Menu control can be improved. This is also true for some other components.
Xubuntu 22.04, beta 15, X11, qtile, 2080 rtx I get around ~2700 fps on idle, when I open a menu and don't move mouse, fps drops to ~1600, if I move my mouse vertically over menu items fast, fps : ~1200 when I swap menus with mouse fast (left-right movement) (menu showing is delayed like ~0.25 seconds) fps drops to 50-600 range I will retest this on clean reboot and without qtile, if it behaviors differently, I will update.
Hi, it's generally a laggy UI when you have a larger project.
I work most of the time in the script editor and the UI has some lags.
For example select a value press CTRL+C and next after CRTL-V it very often does not copy the selected value but it often doubles the current line.
Also good to observe is the mouseover over a class then the editor hangs for a good 1-2s to then refer to the help
Windows 10, Nvidia GTX980
For example select a value press CTRL+C and next after CRTL-V it very often does not copy the selected value but it often doubles the current line.
This is likely related to the shortcut handling regression in Godot 4 with shortcuts using modifier keys (this also occurs with Ctrl + A for Create New Node, for instance). There's already an open issue for this but I can't find it right now.
Just wanted to add my 2 cents in here. In general I have noticed on my end that right clicking an element in the editor (which opens a menu) is very slow and freezes the entire editor, this happens on pretty small projects. Also sometimes when I scroll a list it starts stuttering unless I stop and wait a second before scrolling again (this does not happen consistently)
Generally, I do feel like the Editor is a bit slower in 4.0 comared to 3.5 as well, including in Compatibility mode actually. Menus feel heavier when opened. Swiping though them is not fluid. And typing in the code editor doesn't fell as responsive.
Generally, I do feel like the Editor is a bit slower in 4.0 comared to 3.5 as well, including in Compatibility mode actually. Menus feel heavier when opened. Swiping though them is not fluid. And typing in the code editor doesn't fell as responsive.
The 3.x GLES renderers have received a lot of optimizations over the years – 3.x also lacks multi-window support, which comes with some overhead (creating windows has a cost). It'll take some time until 4.x can come close to 3.x in terms of rendering efficiency.
To reduce the overhead of multi-window support, enable Single Window Mode in the Editor Settings. This means the editor will no longer create a window for every popup or tooltip. The downside is that popups and tooltips will no longer to be able to extend outside the editor window.
Enabling Single Window Mode in the Editor Settings made Godot 4 Editor usable on Windows 11, because it was unbearably slow. Felt like everything was taking a full second to do something.
Single Window Mode False
https://user-images.githubusercontent.com/14341036/227757958-aa004f42-14cb-4f9f-9b47-72e8da283fa3.mp4
Single Window Mode True
https://user-images.githubusercontent.com/14341036/227757966-545be80f-37c2-4455-b3ea-d2e09bda1e36.mp4
@svendixon I can't reproduce this on my Windows setup. Do you have any third-party overlay software installed? If window creation is taking very long, it's most likely due to those overlays needing to be initialized for every newly created window (popups are windows when you don't use single-window mode).
Yep, I tracked it down. It looks like was a thumbnail viewer I have installed to view PSD files in windows explorer that was lagging it. Uninstalling it made it faster. Still not as fast as Single Window Mode though, but much more usable. Thanks!
For me, it's always been responsive, even without single-window mode, but I've got a beefy system so maybe that's why? It does feel a tad more delayed than 3.5 in most instances though. 3.5 felt extremely snappy and responsive in the editor most of the time.
Godot version
4.0.2.stable.mono
System information
OS: Windows 11 CPU: AMD Ryzen 7 3700x 8-core processor GPU: GeForce RTX 3080 (10Gb) RAM: 16 GB (3200mhz) DDR4
For me, it's always been responsive, even without single-window mode, but I've got a beefy system so maybe that's why? It does feel a tad more delayed than 3.5 in most instances though. 3.5 felt extremely snappy and responsive in the editor most of the time.
It's a similar situation for me as well. Godot 4's editor feels like a step back. In the majority cases, I find it even more sluggish than UE5's editor.
Can you reproduce this in 4.0.alpha1? You can download it here. If not, please try subsequent alphas and betas as well.
If you can reproduce this on 4.0.alpha1, you could look into bisecting the regression to greatly speed up troubleshooting.
OK there are two PRs that are/may be relevant to this ticket.
The first one are my fixes to Vulkan CPU/GPU Synchronization. I've measured improvements in latency.
The second one is a fix to a broken semaphore handling when resizing the window. This might be causing performance issues on some drivers after it's triggered (which is quite easy to do actually), but I can't promise that PR will change anything or not.
I also encountered slowness in the editor. I have AMD, this is on 4.1 stable. I'm clicking nodes and sometimes it takes 1-2 seconds to change between them in the same tree, and the project is very small. Here's a video, moving between scenes is also slow but maybe a little more semi expected, but at the end you can see trying to move between nodes in the tree takes sometimes almost a second:
https://github.com/godotengine/godot/assets/73611276/7013e3e9-80da-4261-a42f-745ba9888a22
I'm clicking nodes and sometimes it takes 1-2 seconds to change between them
Yes, I also experience this, but I'm not sure it is same (UI) issue. It may be same and may be Inspector window lag etc. May be you should create separate issue and add reference to this one?
I also encountered slowness in the editor.
I ran into a similar problem on my laptop with an AMD R7 5800H. Godot would freeze for 1.5-3 seconds when I selected a node in a scene, and when I switched between scenes.
I can assume that this is caused by the engine logging any change to the .cfg \ cache files in the ./.godot/editor directory in the root of the project. After I moved the project from my slow HDD to NVMe SSD - engine latency is down to 0, with occasional microfreezes.
Okay, caching\logging is an important part of the engine, but it would be nice to make it an option in the settings and\or do it when closing the engine.
And I’m not mistaken - Godot works in a single-threaded, right?
I ran into a similar problem on my laptop with an AMD R7 5800H. Godot would freeze for 1.5-3 seconds when I selected a node in a scene, and when I switched between scenes.
Tree slowness with large scene trees should be fixed in 4.2.dev. Please test 4.2.dev4 🙂
And I’m not mistaken - Godot works in a single-threaded, right?
Some operations in Godot are multi-threaded, others are single-threaded. There is no clear-cut way to define whether a program is multi-threaded or not.
Tree slowness with large scene trees should be fixed in 4.2.dev. Please test 4.2.dev4 🙂
At the time of writing my comment, I tested in a semi-empty scene (just a few nodes, a initial scene with primitives) in 4.1.1 and in 3.5.2. In 4.1.1 it was slow on HDD, in 3.5.2 it was fast (sometimes with microfreezes). In 4.2-dev4 it seems to be faster to switch scenes, but selecting nodes from a 3D editor is a pain, just like in 4.1.1.
but selecting nodes from a 3D editor is a pain, just like in 4.1.1.
See https://github.com/godotengine/godot/issues/72621.
I get the same issue as the recordings in https://github.com/godotengine/godot/issues/71795#issuecomment-1484003366 in v4.2.stable.official [46dc27791].
It was fine before but the editor got laggy at the same point while working, now even with all scenes closed and after restarting the editor is consistently lagging. The game runs fine and the editor's 3D view lags at first but stabilizes in a few moments.
Single Window Mode fixed it.
Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3070 (NVIDIA; 31.0.15.4633) - AMD Ryzen 9 7950X 16-Core Processor (32 Threads)
