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