EricEzaM
commented
1 year ago Hmm I can't reproduce that menu hover slowness personally - Windows 10, Ryzen 3600 GTX 1080
Open gshadows opened 1 year ago
EricEzaM
commented
1 year ago Hmm I can't reproduce that menu hover slowness personally - Windows 10, Ryzen 3600 GTX 1080
Zireael07
commented
1 year ago 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
commented
1 year ago @Zireael07 Same. Windows 11, Intel 17 10750H, RTX 2060 Max-Q
Calinou
commented
1 year ago Related to https://github.com/godotengine/godot/issues/70869.
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).
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
Can't benchmark, as V-Sync currently can't be disabled with the Compatibility rendering method.
Zireael07
commented
1 year ago 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
commented
1 year ago 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
commented
1 year ago 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
commented
1 year ago 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.
https://user-images.githubusercontent.com/180032/213909749-b32cddca-a986-4cf9-9ac7-afe1bfd978e2.mp4
https://user-images.githubusercontent.com/180032/213909746-67cd21af-ee32-4ad2-8be5-047346da370d.mp4
https://user-images.githubusercontent.com/180032/213909752-439b314e-4372-425a-915b-cd225b1f0351.mp4
https://user-images.githubusercontent.com/180032/213909751-676f9be8-0c0f-4a1d-891a-6aadebd63d57.mp4
https://user-images.githubusercontent.com/180032/213909750-98dadaa9-aa0d-4165-ab3d-86e660597a85.mp4
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.)
gshadows
commented
1 year ago 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
commented
1 year ago 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.
claychinasky
commented
1 year ago 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
commented
1 year ago 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
commented
1 year ago 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
commented
1 year ago 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
commented
1 year ago 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
commented
1 year ago 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
commented
1 year ago 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.
Calinou
commented
1 year ago @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).
svendixon
commented
1 year ago 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!
SirQuartz
commented
1 year ago 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.
4.0.2.stable.mono
OS: Windows 11 CPU: AMD Ryzen 7 3700x 8-core processor GPU: GeForce RTX 3080 (10Gb) RAM: 16 GB (3200mhz) DDR4
PrecisionRender
commented
1 year ago 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.
Calinou
commented
1 year ago 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.
darksylinc
commented
11 months ago 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.
fkeyzuwu
commented
11 months ago 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
gshadows
commented
11 months ago 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?
xenongee
commented
10 months ago 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?
Calinou
commented
10 months ago 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.
xenongee
commented
10 months ago 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.
Calinou
commented
10 months ago but selecting nodes from a 3D editor is a pain, just like in 4.1.1.
ydeltastar
commented
5 months ago 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)
ydeltastar
commented
5 months ago I tested with v4.3.dev.custom_build [b4e2a24c1] and there is much less lag, although Single Window Mode still makes it faster.
Braveo
commented
4 months ago 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:
https://github.com/godotengine/godot/assets/23423003/85b44603-5f89-42f6-a103-6b0fb340174b
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
commented
4 months ago 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
commented
4 months ago 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
commented
4 months ago 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
commented
4 months ago 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
commented
3 months ago 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
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago 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:
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 |
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 |
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 |
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 (15073afe3) - 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
commented
2 months ago As it so appears, my prior analysis is invalidated by the refactor introduced in https://github.com/godotengine/godot/commit/73eff10c76c201a083193c044de1836217b4d72b - 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 (8e2141eac) - 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
commented
2 months ago 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
commented
2 months ago 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
commented
2 months ago 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:
laspencer91
commented
1 month ago 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
commented
1 month ago https://github.com/godotengine/godot/pull/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
commented
1 month ago 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
https://github.com/godotengine/godot/assets/38126357/b62bfb32-cb2b-45c8-94b9-3893b1c5f647
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 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.
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