godot
godot copied to clipboard
godotengine
The tree in the Scene dock has noticeable lag further down you scroll in 4.1
Godot version
v4.1.stable.mono.official [970459615]
System information
Godot v4.1.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1050 Ti (NVIDIA; 31.0.15.3179) - AMD Ryzen 3 3200G with Radeon Vega Graphics (4 Threads)
Issue description
I have a scene with a large amount of InstanceMesh3D, StaticBody3D which are in a Map node. This scene does not cause any lags for me, but as soon as I expand the Map node, my scene starts to lag and it is impossible to work with the project at all. Before that I moved my project from 4.0.2.stable to 4.1.stable. The previous version did not cause such problems.
Steps to reproduce
Create a scene of over +500 MeshInstance3D with any shape that is in a Node3D node. Try to open and close Node3D and you will see the performance drop.
Minimal reproduction project
N/A
Can you please upload an MRP so that other contributors can attempt to reproduce the issue? Without an MRP, it is unlikely anyone will be able to help you
Can you please upload an MRP so that other contributors can attempt to reproduce the issue? Without an MRP, it is unlikely anyone will be able to help you
Of course, here's my test project that demonstrates this problem.
I can't speak for any problem in the Inspector, since this is a very simple scene, composition wise, just Node3Ds. But the scene tree starts to lag like hell the more down you scroll (and gets back to snappy once you scroll back to top). Not sure if this didn't happen in 4.0.3, checking that now. But it's pretty bad regardless.
Edit: Can confirm that 4.0.3 is buttery smooth throughout the whole tree.
I tried the above MRP on 4.0.1 and 4.1, on my pc (Arch Linux, 1080Ti) There is a noticeable lag in 4.1 which does not exist in 4.0.1 (which doesn't make it impossible to edit, but lower hardware) if I scroll down on the node tree
Edit: Posting videos of both: 4.0.1 -> https://files.catbox.moe/jnzbx5.mkv 4.1 -> https://files.catbox.moe/8lbts3.mkv
The issue is not related to the editor, any Tree control is affected. Here's one with 10000 items, that exhibits same behavior:
Edit: The issue first appeared between 4.1.dev2 and 4.1.dev3. The biggest suspect is https://github.com/godotengine/godot/pull/76532. cc @dalexeev @bruvzg
I can't speak for any problem in the Inspector, since this is a very simple scene, composition wise, just
Node3Ds. But the scene tree starts to lag like hell the more down you scroll (and gets back to snappy once you scroll back to top). Not sure if this didn't happen in 4.0.3, checking that now. But it's pretty bad regardless.Edit: Can confirm that 4.0.3 is buttery smooth throughout the whole tree.
Thanks for confirming that this is a bug. By the way, is it possible to find the commit that changed the rendering or loading of nodes in the scene tree?
By the way, is it possible to find the commit that changed the rendering or loading of nodes in the scene tree?
It's an issue with Tree, not with the nodes in the editor. To find the commit you need to bisect between a known good point and a known bad point. I've already done a high-level bisection and check which official release was the first to exhibit the problem (4.1.dev3). Based on the list of changes, there is a good chance that the problem comes from the PR I linked above. To be sure one can try building the editor one commit before that PR was merged, or try reverting it (not trivial at this point, relevant code has changed).
@dalexeev From the behavior and from the changeset of your PR, I think the issue is rooted in the fact that we now need to compute something about every preceding tree item, whereas before we would ignore items which are not currently on screen.
Which is admittedly a pretty typical issue for this kind of control and this kind of situation. Since offset is uneven now, cannot be calculated by using the number of items before the first visible one, we need to cache something.
After investigating the profiler data, I tentatively think we should try caching Tree::get_column_minimum_width(). I will try to do this tomorrow.
After investigating the profiler data, I tentatively think we should try caching
Tree::get_column_minimum_width(). I will try to do this tomorrow.
Thank you so much. How I can get this fix or wait untill 4.2.devx version?
How I can get this fix or wait untill 4.2.devx version?
I opened PR #79325 which you can test. Yes, this is a change for 4.2, but if the PR is merged and considered safe enough, it will be cherry-picked for a 4.1.x maintenance release.