Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor EditorNode get icon #101435

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

YYF233333
Copy link
Contributor

@YYF233333 YYF233333 commented Jan 11, 2025

Add a fast path for built-in class in EditorNode::get_class_icon.

#78645 MRP with 28K objects now runs smoothly, 91K objects still sucks.

Would be good if someone knows what EditorNode::get_object_icon does could refactor these code.

Refactor get icon logic.

  • Split _get_class_or_script_icon into _get_class_icon and _get_script_icon.
  • Change get_class/object_icon to avoid multiple checking.
  • Use file extension to identify resource path. This should be cheaper than ResourceLoader::exists.

Test with test_custom_icon.zip, class_name and @icon seems to work without problem. And the performance boost remains true.

@YYF233333 YYF233333 changed the title Return fast for built-in class icon. Return fast for built-in class icon Jan 11, 2025
@Calinou Calinou added this to the 4.4 milestone Jan 11, 2025
editor/editor_node.cpp Outdated Show resolved Hide resolved
@YYF233333 YYF233333 requested a review from a team as a code owner January 12, 2025 14:48
@YYF233333 YYF233333 changed the title Return fast for built-in class icon Refactor EditorNode get icon Jan 12, 2025
@akien-mga akien-mga requested a review from KoBeWi January 12, 2025 16:45
@777joe
Copy link

777joe commented Jan 12, 2025

Tried this out. This fixes #98666 too.

Copy link
Member

@Calinou Calinou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested locally, it works as expected. It's faster overall but due to remaining bottlenecks, scrolling large Trees is still sluggish, especially when near the bottom.

Code looks good to me.

All tests done with an optimized editor build with theMRP from #78645.

I've also tried the MRP of this PR with 16,384 nodes (duplicated from the original 4 nodes) but couldn't spot much of a performance difference when scrolling.

Local

master

master_local.mp4

This PR

pr_local.mp4

Remote

Stutters due to Tree updates being performed every second are still present.

master

master_remote.mp4

This PR

pr_remote.mp4

editor/editor_node.cpp Outdated Show resolved Hide resolved
editor/editor_node.cpp Outdated Show resolved Hide resolved
@KoBeWi
Copy link
Member

KoBeWi commented Jan 24, 2025

This looks mostly like a cleanup, while #101489 is a complete solution. The key point is avoiding to load scripts.

Still, it does not have problems I mentioned in #101489 (comment), and if it's indeed faster, then it's fine for now. The two PRs don't seem mutually exclusive.

Co-authored-by: Tomasz Chabora <kobewi4e@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants