-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
Store taffy node keys in components #8297
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
base: main
Are you sure you want to change the base?
Store taffy node keys in components #8297
Conversation
* Added new components "TaffyNode" and "TaffyParent" * Added `insert_node` method to `FlexSurface` * Added `make_measure` function to `flex` module. * `flex_node_system` stores taffy nodes keys in the "TaffyNode" and "TaffyParent" components instead of looking them up using the `entity_to_taffy` map.
You added a new example but didn't add metadata for it. Please update the root Cargo.toml file. |
* added `primary_node` and `physical_to_logical_factor` fields to `FlexSurface`. * added the `Transforms` variant to the `UiSystem` enum. * split off the transforms update from `flex_node_system` into a separate function `update_ui_node_transform` and scheduled it to run after `UiSystem::Flex` and before `TransformSystem::TransformPropagate`.
Is it possible to remove the |
I don't think so, it's needed for handling children and removing orphaned taffy nodes. |
DioxusLabs/taffy#326 (or more likely, parts of this PR split out into their own PRs) will allow this. It's supposed to be possible with the current version of the LayoutTree trait, but in practice the current version has things like SlotMap keys in the trait function signatures which make it impractical. With that approach all Taffy data (input styles, parent-children relationships, and and output layouts) would be stored by Bevy (however it chose to do so). Care would need to be taken to ensure performance parity though, as Taffy's SlotMaps are backed by Vecs and are therefore very fast to access. Not sure if it's possible to get Vec backed storage in bevy_ecs that only applies to UI nodes? |
Although to this specific issue there might be a simpler solution. My understanding is that a Bevy component typically is a HashMap, so a Query of a component containing the Taffy node key ought to function the same as a HashMap containing the mapping I think. |
Example |
1 similar comment
Example |
* Renamed `flex_node_system` to `update_ui_layout`. * Replaced the `window_nodes` map field of `UiSurface` with a single `window_node` node field.
…ield and `get` method. Edited the doc comment for `insert_node`.
…e `layout` module. Renamed some variables to be consistant with the name change. `UiSurface::insert_node` reuses the previous taffy node associated to the given `entity`, if one exists.
Improved the implementation and reduced it down to just the minimum necessary changes without any extra systems. Should be ready to merge, but I'll make some new tests for |
Changed the ordering of parameters for the `from_style` and `LayoutContext::new` functions to put the most important parameter first. `UiSurface`: Added a test `uisurface_insert_and_remove_nodes`.
…ckshonpe/bevy into store-taffy-keys-in-components
@ickshonpe What's the motivation for this change? Performance? If so it would be good to get some perf numbers vs. main for the latest version. |
It's increasing performances at the cost of memory. Not sure it's worth it in this case, as the gain is 0.2ms in an extreme UI case... |
I do like the idea of breaking this out from a centralized hashmap (and perf wins are good), but having multiple sources of truth that need syncing gives me some pause. I'll need to give this some thought, which sadly will need to wait until 0.12. |
Objective
Store the taffy node keys in a component on the UI node entities instead of using the
UiSurface::entity_to_taffy
map to look them up.Changelog
UiKey
:UiKey
is a new component with a single field:taffy_id: taffy::node::Node
and a methodget
to retrieve its value.UiKey::default()
creates aUiKey
with a null taffy id value. This should be the only way for users to instantiate aUiNodeId
component. If multiple entities with the same non-nullUiKey::taffy_id
exist, the UI layout will not update correctly.UiKey
component to be included in the UI layout.NodeBundle
,ImageBundle
,TextBundle
,ButtonBundle
:UiKey
component has been added to each of these bundles.UiSurface
:upsert_node
method has been split into separate methods:insert_node
andset_style
.get_layout
. The Taffy layout is accessed directly instead.taffy::node::Node
parameter instead sinceentity_to_taffy
lookups are no longer needed.LayoutError
ui_layout_system
Migration Guide
UiKey
is a new component that is managed automatically byui_layout_system
and should only be instantiated withUiKey::default()
. It is used to identify a UI node in the UI's internal layout tree.UiKey
has been added to each of the UI node bundles.