Godot 4 editor UI (menus) significantly slower than 3.x

[gshadows]

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

[EricEzaM]

Hmm I can't reproduce that menu hover slowness personally - Windows 10, Ryzen 3600 GTX 1080

[Zireael07]

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

[PrecisionRender]

@Zireael07 Same. Windows 11, Intel 17 10750H, RTX 2060 Max-Q

[Calinou]

Related to #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.

[Zireael07]

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.

[Calinou]

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?

[Zireael07]

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)

[Calinou]

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

3_gles3_vsync_on.mp4

GLES3 V-Sync disabled

3_gles3_vsync_off.mp4

4.0.beta13

Forward Plus V-Sync enabled

4_forward_plus_vsync_on.mp4

Forward Plus V-Sync disabled

4_forward_plus_vsync_off.mp4

Compatibility V-Sync enabled

4_compatibility_vsync_on.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).

#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.)

[gshadows]

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.

[Maran23]

For submenus, this is related: #70361
But in general, I feel that the Menu control can be improved. This is also true for some other components.

[claychinasky]

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.

[MikeSchulze]

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

[Calinou]

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.

[MunWolf]

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)

[hakro]

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.

[Calinou]

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.

[svendixon]

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

2023-03-26.01-50-57.mp4

Single Window Mode True

2023-03-26.01-49-42.mp4

[Calinou]

@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).

[ydeltastar]

I get the same issue as the recordings in #71795 (comment) in v4.2.stable.official [46dc277].

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)

[ydeltastar]

I tested with v4.3.dev.custom_build [b4e2a24] and there is much less lag, although Single Window Mode still makes it faster.

[Braveo]

Currently in v4.3.dev5.mono and I'm currently still getting some lag in multi-window mode.

Dropdown menus seem to appear black right before fully rendering something:

Resizing windows is incredibly sluggish as well:

Godot_v4.3-dev5_mono_win64_uBvh2mXbgd.mp4

Another thing I've noticed is how there is a slight input delay with moving around in the viewport, where my mouse cursor would be trailed by the actual viewport. Keep in mind that I am on a laptop here (plugged in), and my desktop PC has had different results (that I cannot currently record with it due to no access to it right now).

[Calinou]

Dropdown menus seem to appear black right before fully rendering something:

This is because every dropdown is a window, which takes some time to be initialized. Making dropdowns windows allows them to extend outside the main editor window, so this is something we'd like to keep;

If you enable Single Window Mode in the editor settings, this delay should go away, but popups won't be able to extend outside the main window anymore.

We should figure out a way to initialize the color to something that's as close as possible to the actual popup background color still.

Another thing I've noticed is how there is a slight input delay with moving around in the viewport, where my mouse cursor would be trailed by the actual viewport.

This is not something that can be completely resolved since the mouse cursor is drawn by the OS (and never has to wait for the application to update its rendering). Even with V-Sync off and a very high uncapped framerate, there will be some delay.

Keep in mind that I am on a laptop here (plugged in),

Which rendering method are you using? Is Godot running on the integrated GPU or dedicated GPU (if you have one)? Godot will default to the dedicated GPU on Forward+/Mobile, and the integrated GPU on Compatibility unless you force something else in the graphics driver control panel (or unless a MUX switch is used to disable the integrated GPU entirely).

Rendering at high resolutions on integrated graphics is pretty slow, so you may not be able to sustain 60 FPS in the editor even on a 2D project. 2D batching should improve this somewhat for Forward+/Mobile in the future, but it's not a silver bullet.

[Braveo]

This is because every dropdown is a window, which takes some time to be initialized. Making dropdowns windows allows them to extend outside the main editor window, so this is something we'd like to keep;

I think it's less of that being an issue and more of that windows can feel very sluggish altogether, including the initialization. I recently tested multiple windows with different scenarios, such as popping the script editor to a new window, and noticed a heavy amount of lag even when just typing and doing anything on that window. Unfortunately, the scripting editor can't be popped to a new window in Single Window Mode, so I'm stuck with that for now.

This is not something that can be completely resolved since the mouse cursor is drawn by the OS (and never has to wait for the application to update its rendering). Even with V-Sync off and a very high uncapped framerate, there will be some delay.

That's completely fair, I'm just curious on why that is the case. Some other applications have synced up with the mouse much better to the point where it's unnoticeable though, which is mainly why I brought this up.

Which rendering method are you using? Is Godot running on the integrated GPU or dedicated GPU (if you have one)? Godot will default to the dedicated GPU on Forward+/Mobile, and the integrated GPU on Compatibility unless you force something else in the graphics driver control panel (or unless a MUX switch is used to disable the integrated GPU entirely).

I'm currently using Forward+, on a Laptop with a dedicated mobile GPU (RTX 3060). There is also an integrated GPU (AMD Radeon) that switches depending on context (such as being unplugged).

[Braveo]

UPDATE: I happened to be using Godot 4.3.dev5 in battery mode, with compatibility rendering, and noticed that windowed mode was working much smoother, even if it wasn't entirely perfect. I'm just surprised that having my laptop on battery somehow made multi window rendering work. I'm not sure if it's my laptop utilizing integrated graphics, or compatibility rendering, or both that made this condition bearable.

[Calinou]

I'm just surprised that having my laptop on battery somehow made multi window rendering work. I'm not sure if it's my laptop utilizing integrated graphics, or compatibility rendering, or both that made this condition bearable.

Your laptop surely defaults to the IGP for OpenGL applications, so the Compatibility rendering method runs on the IGP. While this is generally slower than the dedicated GPU, it may result in lower input lag because there's no offloading occurring to the dedicated GPU (which is a relatively slow process).

[redsett]

I randomly run into this as well. "Sometimes" the editor is very slow like the reports others have posted. But if I restart the editor enough times... eventually it gets into a state that isn't slow.

Thankfully the single window mode seems to fix it. At least in my limited testing.

This has been an issue for me since 4.0.

Details:
Forward+ (needed for my project)

Godot version: 4.2.stable

System information:
OS: Windows 10
CPU: AMD Ryzen Threadripper PRO 3945WX
GPU: GeForce RTX 3090
RAM: 128 GB

[kadenkat]

I was having similar issues as described. Disabling HDR fixed my problem, and oddly, re-enabling HDR did not cause the issue to return (even after relaunching Godot). Unfortunately, I think my issue was different than this one, but hopefully, my comment will be helpful to someone else.

To describe my issue further, when I hovered over items, like the Root Node options, 2D Scene, 3D Scene, etc, my mouse stuttered a lot. I also noticed the screen brightness changed ever so slightly and my GPU would go up to about 5%-10%. I did not experience this stuttering when using Godot on my non-HDR monitor. I concluded that HDR might be the problem and tried disabling it. The stuttering was gone immediately, much to my satisfaction.

Additional info:
I had HDR enabled when I opened the application for the first time, which opened on my primary monitor.

Monitor: Alienware AW3423DW
OS: Windows 11 Pro, 23H2
CPU: AMD Ryzen 7 5700X 8-Core Processor
GPU: GeForce RTX 3080 Ti
RAM: 32GB

[kadenkat]

I was having similar issues as described. Disabling HDR fixed my problem, and oddly, re-enabling HDR did not cause the issue to return (even after relaunching Godot). Unfortunately, I think my issue was different than this one, but hopefully, my comment will be helpful to someone else.

To describe my issue further, when I hovered over items, like the Root Node options, 2D Scene, 3D Scene, etc, my mouse stuttered a lot. I also noticed the screen brightness changed ever so slightly and my GPU would go up to about 5%-10%. I did not experience this stuttering when using Godot on my non-HDR monitor. I concluded that HDR might be the problem and tried disabling it. The stuttering was gone immediately, much to my satisfaction.

Additional info: I had HDR enabled when I opened the application for the first time, which opened on my primary monitor.

Monitor: Alienware AW3423DW OS: Windows 11 Pro, 23H2 CPU: AMD Ryzen 7 5700X 8-Core Processor GPU: GeForce RTX 3080 Ti RAM: 32GB

Bleh. Well, I still have the lag issue even on my non-HDR monitor. Toggling HDR does seem to affect the symptoms, so I think it's still related somehow.

I noticed on my non-HDR monitor the overall brightness will change when I hover over different items, much like before.

Additional weirdness: I tried capturing the stuttering with ScreenToGif, but while recording, the issue went away. I have no idea what to make of this, but I'm starting to think it's not Godot's fault; there's just something about my system that it doesn't like.

EDIT: Yeah. I think my multiple monitor setup and refresh rates are messing with Godot; however, other applications don't behave this way, so I'm not sure why Godot is having an issue.

[Calinou]

I have HDR (+ RTX HDR) enabled on my desktop and can't reproduce this issue on Windows 11 23H2. That said, RTX HDR isn't great on the Godot editor (or non-game applications made with it), as it will keep disabling itself when the editor/app doesn't redraw for a few seconds. It'll re-enable itself once it redraws for any reason.

You might want to check if you can reproduce this issue when the GPU has its power management forced to Prefer maximum performance in NVIDIA Control Panel (in Manage 3D Settings).

[nta]

On my machine, this is moderately slow (taking around 300ms to populate a window such as the context menu). Some quick profiling here using ETW (on Windows 11 24H2 with NVIDIA 555 drivers) showed that Godot is redundantly recreating the Vulkan swapchain from a few code paths for every window create:

Code path 1:

Window::_make_window -> DisplayServerWindows::show_window -> DisplayServerWindows::_update_window_style

Line #	Process	Thread Name	Thread ID	Stack	Count	Weight (in view) (ms)
34				|    |    |    |    |    |- godot.windows.editor.x86_64.exe!Window::set_visible	96	96.074000
35				|    |    |    |    |    |    godot.windows.editor.x86_64.exe!Window::_make_window	96	96.074000
36				|    |    |    |    |    |    |- godot.windows.editor.x86_64.exe!DisplayServerWindows::show_window	26	26.158500
37				|    |    |    |    |    |    |    godot.windows.editor.x86_64.exe!DisplayServerWindows::_update_window_style	26	26.158500
38				|    |    |    |    |    |    |    win32u.dll!ZwUserSetWindowPos	26	26.158500
39				|    |    |    |    |    |    |    ntoskrnl.exe!KiSystemServiceCopyEnd	26	26.158500
40				|    |    |    |    |    |    |    win32k.sys!NtUserSetWindowPos	26	26.158500
41				|    |    |    |    |    |    |    win32kfull.sys!NtUserSetWindowPos	26	26.158500
42				|    |    |    |    |    |    |    win32kfull.sys!xxxSetWindowPos	26	26.158500
43				|    |    |    |    |    |    |    win32kfull.sys!xxxEndDeferWindowPosEx	26	26.158500
44				|    |    |    |    |    |    |    |- win32kfull.sys!xxxSendChangedMsgs	25	25.158500
45				|    |    |    |    |    |    |    |    win32kfull.sys!xxxSendPosMessage	25	25.158500
46				|    |    |    |    |    |    |    |    win32kfull.sys!xxxSendTransformableMessageTimeout	25	25.158500
47				|    |    |    |    |    |    |    |    win32kfull.sys!xxxSendMessageToClient	25	25.158500
48				|    |    |    |    |    |    |    |    win32kfull.sys!SfnINLPWINDOWPOS	25	25.158500
49				|    |    |    |    |    |    |    |    ntoskrnl.exe!KeUserModeCallback	25	25.158500
50				|    |    |    |    |    |    |    |    ntdll.dll!KiUserCallbackDispatcherContinue	25	25.158500
51				|    |    |    |    |    |    |    |    user32.dll!__fnINLPWINDOWPOS	25	25.158500
52				|    |    |    |    |    |    |    |    user32.dll!DispatchClientMessage	25	25.158500
53				|    |    |    |    |    |    |    |    user32.dll!UserCallWinProcCheckWow	25	25.158500
54				|    |    |    |    |    |    |    |    godot.windows.editor.x86_64.exe!WndProc	25	25.158500
55				|    |    |    |    |    |    |    |    godot.windows.editor.x86_64.exe!DisplayServerWindows::WndProc	25	25.158500
56				|    |    |    |    |    |    |    |    godot.windows.editor.x86_64.exe!VulkanContext::_update_swap_chain	25	25.158500
57				|    |    |    |    |    |    |    |    |- vulkan-1.dll!terminator_CreateSwapchainKHR	17	17.112000

Code path 2:

Window::_make_window -> DisplayServerWindows::window_set_mouse_passthrough

Line #	Process	Thread Name	Thread ID	Stack	Count	Weight (in view) (ms)
37				|    |    |    |    |    |    |- godot.windows.editor.x86_64.exe!DisplayServerWindows::window_set_mouse_passthrough	25	25.188000
38				|    |    |    |    |    |    |    user32.dll!SetWindowRgn	25	25.188000
39				|    |    |    |    |    |    |    uxtheme.dll!ThemeSetWindowRgn	25	25.188000
40				|    |    |    |    |    |    |    user32.dll!RealSetWindowRgn	25	25.188000
41				|    |    |    |    |    |    |    win32u.dll!NtUserSetWindowRgn	25	25.188000
42				|    |    |    |    |    |    |    ntoskrnl.exe!KiSystemServiceCopyEnd	25	25.188000
43				|    |    |    |    |    |    |    win32k.sys!NtUserSetWindowRgn	25	25.188000
44				|    |    |    |    |    |    |    win32kfull.sys!NtUserSetWindowRgn	25	25.188000
45				|    |    |    |    |    |    |    win32kfull.sys!xxxSetWindowRgn	25	25.188000
46				|    |    |    |    |    |    |    win32kfull.sys!xxxEndDeferWindowPosEx	25	25.188000
47				|    |    |    |    |    |    |    win32kfull.sys!xxxSendChangedMsgs	25	25.188000
48				|    |    |    |    |    |    |    win32kfull.sys!xxxSendPosMessage	25	25.188000
49				|    |    |    |    |    |    |    win32kfull.sys!xxxSendTransformableMessageTimeout	25	25.188000
50				|    |    |    |    |    |    |    win32kfull.sys!xxxSendMessageToClient	25	25.188000
51				|    |    |    |    |    |    |    win32kfull.sys!SfnINLPWINDOWPOS	25	25.188000
52				|    |    |    |    |    |    |    ntoskrnl.exe!KeUserModeCallback	25	25.188000
53				|    |    |    |    |    |    |    ntdll.dll!KiUserCallbackDispatcherContinue	25	25.188000
54				|    |    |    |    |    |    |    user32.dll!__fnINLPWINDOWPOS	25	25.188000
55				|    |    |    |    |    |    |    user32.dll!DispatchClientMessage	25	25.188000
56				|    |    |    |    |    |    |    user32.dll!UserCallWinProcCheckWow	25	25.188000
57				|    |    |    |    |    |    |    godot.windows.editor.x86_64.exe!WndProc	25	25.188000
58				|    |    |    |    |    |    |    godot.windows.editor.x86_64.exe!DisplayServerWindows::WndProc	25	25.188000
59				|    |    |    |    |    |    |    godot.windows.editor.x86_64.exe!VulkanContext::_update_swap_chain	25	25.188000
60				|    |    |    |    |    |    |    |- vulkan-1.dll!terminator_CreateSwapchainKHR	17	17.148300

Code path 3:

Window::_make_window -> Window::_update_window_size

Line #	Process	Thread Name	Thread ID	Stack	Count	Weight (in view) (ms)
38				|    |    |    |    |    |    |- godot.windows.editor.x86_64.exe!Window::_update_window_size	25	25.127900
39				|    |    |    |    |    |    |    godot.windows.editor.x86_64.exe!DisplayServerWindows::window_set_size	25	25.127900
40				|    |    |    |    |    |    |    godot.windows.editor.x86_64.exe!VulkanContext::_update_swap_chain	25	25.127900
41				|    |    |    |    |    |    |    |- vulkan-1.dll!terminator_CreateSwapchainKHR	17	16.919300

Code path 4:

Window::_make_window -> DisplayServerWindows::create_sub_window

Line #	Process	Thread Name	Thread ID	Stack	Count	Weight (in view) (ms)
73				|    |    |    |    |    |    |- godot.windows.editor.x86_64.exe!DisplayServerWindows::create_sub_window	20	19.599600
74				|    |    |    |    |    |    |    godot.windows.editor.x86_64.exe!DisplayServerWindows::_create_window	20	19.599600
75				|    |    |    |    |    |    |    |- godot.windows.editor.x86_64.exe!VulkanContextWindows::window_create	14	13.599600
76				|    |    |    |    |    |    |    |    godot.windows.editor.x86_64.exe!VulkanContext::_window_create	14	13.599600
77				|    |    |    |    |    |    |    |    godot.windows.editor.x86_64.exe!VulkanContext::_update_swap_chain	14	13.599600

Each swapchain creation leads to a pretty convoluted code path in the NVIDIA ICD, including some kernel-mode D3D12 backing objects (likely for compositor interop), and possibly also invoking user-installed Vulkan layers that would have a say as well. This could hurt a lot less if each window would only create a single swapchain when opened, instead of... four of them (create, resize, and two underlying attribute changes).

System info for reference:

Godot v4.2.2.stable (15073af) - Windows 10.0.26120 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4080 (NVIDIA; 32.0.15.5585) - 13th Gen Intel(R) Core(TM) i7-13700K (24 Threads)

I should, perhaps, try this with latest trunk rather than stable - it seems a lot of logic here was refactored for D3D12 work.

[nta]

As it so appears, my prior analysis is invalidated by the refactor introduced in 73eff10 - instead of the old code path calling vkCreateSwapChainKHR (via VulkanContext::_update_swap_chain) willy-nilly, the new logic seems to unify this to being called in one place only - and, indeed, running current master on the same machine has fairly better performance opening context menus or popup windows.

Godot v4.3.beta (8e2141e) - Windows 10.0.26120 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4080 (NVIDIA; 32.0.15.5585) - 13th Gen Intel(R) Core(TM) i7-13700K (24 Threads)

However, it still does not appear to be on par with the OpenGL code path, which feels almost instant... I'm not sure how to interpret the profiling results I'm seeing now, either.

[Braveo]

For Nvidia drivers, the Vulkan/OpenGL present method as 'Prefer native' instead of 'Prefer layered on DXGI swapchain' fixes this issue for me (in Godot 4.2). However, I have a laptop that uses the iGPU (Radeon) for display and dGPU (RTX), and Radeon graphics settings seem to have no out of the box option for this, so I'm curious what the change will do in 4.3 after the refactor.

[Calinou]

Thanks for the thorough investigation!

However, it still does not appear to be on par with the OpenGL code path, which feels almost instant... I'm not sure how to interpret the profiling results I'm seeing now, either.

It's known that creating Vulkan/D3D12 windows takes more time than OpenGL windows (regardless of OS or framework/library used), due to the modern low-level APIs featuring more layers of complexity. This is why the project manager always uses OpenGL unless told otherwise with a CLI argument.

[darksylinc]

It's known that creating Vulkan/D3D12 windows takes more time than OpenGL windows (regardless of OS or framework/library used), due to the modern low-level APIs featuring more layers of complexity. This is why the project manager always uses OpenGL unless told otherwise with a CLI argument.

That being said I can think of two things to explore:

1. Look into how many times a swapchain gets recreated. Ideally it should be 1 per window spawned. An unfortunate chain of resize events may lead to multiple unnecessary swapchain recreations. It may be possible to mark the event as dirty and only actually create swapchain when all events are done processing (assuming we're recreating the swapchain way more than necessary).
2. Instead of opening & closing windows on demand, hide and unhide a pool of windows. When one is needed, the window is unhidden and recycled.

[laspencer91]

Same issue where clicking menu items took about 1 second to open the menu. This was a frustrating experience, and only began occurring when my project got to medium size. It caused me to consider moving my project to Unity, it was that frustrating.

Enabling single window mode seems to solve the problem. It is not ideal, but I will live with it.

[clayjohn]

#86029 should help a bit here. It removes one case of redundant swapchain re-creation.

I suspect there are a few more cases we can track down and stamp out before giving up

[Stealcase]

Found this thread after hitting a really nasty latency with Godot 4.2.2 in the editor. CPU is at 1% and GPU never exceeds 25%.

When clicking, it takes almost a full second before the click is rendered. When writing, I can write 2+ letters before the screen actually responds. Moving my mouse drastically, forces a re-render, which speeds up the process. But this is impossible to work with.

It does not matter if I'm using Forward+, Compatibility or Mobile: I have the issues regardless.

Godot 4.2.2.Fedora
OS: Fedora 40
CPU: AMD Ryzen 7 5800X × 16
GPU: RTX 3060 TI
Kernel driver in use: nvidia
Kernel modules: nouveau, nvidia_drm, nvidia
NVIDIA Driver Version: 550.90.07
NVML Version: 2.550.90.07
Linux 6.9.4-200.fc40.x86_64
GNOME: 46
DisplaySystem: Wayland

In this video, I click then move the mouse immediately. Notice the latency from >00:10

2024-06-20.21-27-12.mp4

I'm going to try some things mentioned in this thread, like switching to single window mode.
EDIT:
Single window mode didn't help.

EDIT 2:
my issue seems to be entirely related to NVIDIA Driver Version: 550.90.07 and running Wayland.

• I could recreate the same type of cursor bug in Obsidian, and Someone else had the same issue
  I switched back to Nouveau drivers and Godot editor runs smooth again.

I suspect this has something to do with Implicit Sync vs Explicit sync, and Nvidia doesn't support Explicit Sync on wayland until Driver version 555.42.02 but it's still in beta and not available on my distro's repos.
Sharing here for posterity for whoever might have the same issue.

[mikeandtherest]

For Nvidia drivers, the Vulkan/OpenGL present method as 'Prefer native' instead of 'Prefer layered on DXGI swapchain' fixes this issue for me (in Godot 4.2). However, I have a laptop that uses the iGPU (Radeon) for display and dGPU (RTX), and Radeon graphics settings seem to have no out of the box option for this, so I'm curious what the change will do in 4.3 after the refactor.

Thanks! This fixed it for me. It was lagging so bad on mouse move, whenever I would hover over a UI element which showed a tooltip. And both displays were flickering for 1/10 of a second when that happened.

Godot 4.2.2 (Forward+ mode)
Win 10 Pro.
Nvidia RTX 3090, driver ver. 556.12 (G-Sync enabled on both 4K 144hz displays)

[ChildLearningClub]

Could this be at all related to the focus handling, or the querying of the find_next_valid_focus() and find_prev_valid_focus() of control nodes? https://github.com/godotengine/godot/blob/master/scene/gui/control.cpp#L2002

2024-09-01.19-41-21.mp4

I have attempted vsync off, single window mode, and the "Prefer native" there also appears to be no bottleneck with the CPU or GPU. Simply, the more control nodes, the slower the entire interface becomes.

---

• EDIT UPDATE: It appears that my issue is not related. Each of my Button Control nodes had a SubViewport, which when removed, also removed any lag that I had.

[4x3lpri3t0]

What fixed it for me was disabling G-Sync.

[Calinou]

What fixed it for me was disabling G-Sync.

This should no longer be necessary to do since 4.3 thanks to #93737.

[4x3lpri3t0]

What fixed it for me was disabling G-Sync.

This should no longer be necessary to do since 4.3 thanks to #93737.

I'm using 4.3 tho, so, I don't know. I'm just sharing this in case it helps someone.