-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Filter UI traversal to only Node and GhostNode #15746
Conversation
This means the warning in |
Right! Any ideas on how we could do that? A system just for the warning? 🤔 |
Ah yeah we definitely want to retain that warning. The wins here aren't worth dropping that. |
Looks like the warning actually never prints, since One solution would be for the UiChildren iterator to return |
Wouldn't that basically mean we still traverse all non-UI entities? To check the descendants. Also the warning would still only show up for I think for this warning to really work anywhere, it needs to be decoupled from the layout system completely. How about a system like this? fn warn_ui_entity_in_non_ui_hierarchy(
nodes_with_changed_parent: Query<(Entity, &Parent), (With<Node>, Changed<Parent>)>,
ui_entities: Query<Entity, Or<(With<Node>, With<GhostNode>)>>,
) {
for (entity, parent) in nodes_with_changed_parent.iter() {
if !ui_entities.contains(parent.get()) {
warn!(
"Styled child ({entity}) in a non-UI entity hierarchy. You are using an entity \
with UI components as a child of an entity without UI components, your UI layout may be broken."
);
}
}
} |
Yeah this would catch orphaned sub-trees (non-UI -> UI without any preceding UI). Main downside is |
Huh, I had no idea that’s how Since a Node without parent is a valid root node, we shouldn’t really need to care about removals for this warning system. |
This seems viable, although now the perf issue is frames where you spawn a big bunch of entities in a hierarchy (like a scene, or a bunch of UI) will become even more expensive. |
Maybe we can include the warning system conditionally using Just have to decide between @alice-i-cecile @cart do you have any preference here? |
I like this idea.
HierarchyEvent is a blunt-force tool, given that it is unfiltered. I personally think we should reconsider its existence entirely. Consuming that event is committing to iterating every hierarchy change across the entire world (and then checking if each change matches your criteria). Pretty much nobody should want to that. Producing those events feels likes a fixed cost that we shouldn't need to pay for most things. Given that we're already iterating every UI node entity here, it feels like we might as well just insert our logic there (check if parent has changed, and if so, check if the parent has Node or GhostNode) |
Done! Tested with the following:
Triggered just fine 👍 Decided not to do any I think this is ready for reviews now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a new comment
Co-authored-by: UkoeHB <37489173+UkoeHB@users.noreply.github.com>
Objective
With the warning removed in #15736, the rules for the UI tree changes.
We no longer need to traverse non
Node
/GhostNode
entities.Solution
Or<(With<Node>, With<GhostNode>)>
to the child traversal query so we don't unnecessarily traverse nodes that are not part of the UI tree (like text nodes).Testing