UI Node's transform is sometimes incorrectly calculated about bevy HOT 17 CLOSED

@porkbrain I think you should reopen this issue, because taffy's ratio blindness is just a part of problem, the issue which we mentioned contains description of bug, that is stable and relates to images, but root node here is not image rather container! Every run we get same result there, but bug in this issue is floating. Second part (more important) of this problem is that some times node lives in zero-sized environment!
I tried figure out why calculated size of node contains zero and here is results of investigation:

1. calculated_size gets zero from rounded_size, which gets zero from layout_size, which gets zero from layout, which gets zero from ui_surface, which takes this info from taffy. Why?
2. Because earlier, before starting this recursion ui_surface feeds taffy layout with available_space, which is set by render_target_resolution, which was taken from camera.size. All of them some times are (0, 0). Why?
3. Because camera.size was set by (0, 0) earlier from camera.physical_viewport_size(), which gets zeros from physical_target_size(), which gets zeros from camera.computed.target_info.physical_size. Why?
4. Because camera.computed.target_info is set from new_computed_target_info, which is set from normalized_target under certain conditions. So why this mechanism sometimes does not work correctly?
5. I didn't figured out yet, but I could try later. I assume that the sequence of launching the systems for spawning camera, attaching it to window and determining it's properties is important here. Maybe @Aceeri or @Weibye can correct me here?

Any way looks like taffy is not the source of problem here rather victim of circumstances

from bevy.

I'd really like a minimal reproducible example. Failing that, a reproducible example at all so we can test fixes would be super useful.

Normally I'd tell you to test this upstream in taffy, but this definitely doesn't seem like the issue. Testing it against main (after #10690) might be useful though.

from bevy.

I seperated out the relevant code to this repo. When I run this repo a few times, I encounter the problem.

1. Run the code
2. Press spacebar
3. Close the project
4. Repeat until one time the UI is spawned but not visible

from bevy.

I think

pub fn toggle_spawn(
    mut cmd: Commands,
    asset_server: Res<AssetServer>,

    camera: Query<Entity, With<DialogCamera>>,
    root: Query<Entity, With<DialogUiRoot>>,
    windows: Query<&Window, With<PrimaryWindow>>,
) {
    ...
    let width = if let Ok(window) = windows.get_single() {
        Val::Px(window.width())
    } else {
        Val::Vw(100.0)
    };

    let root = cmd
        .spawn((
            Name::new("Portrait dialog root"),
            DialogUiRoot,
            TargetCamera(camera),
            RenderLayers::layer(25),
            NodeBundle {
                // centers the content
                style: Style {
                    width,
                    bottom: Val::Px(0.0),
                    position_type: PositionType::Absolute,
                    flex_direction: FlexDirection::RowReverse,

                    ..default()
                },
                ..default()
            },
        ))
        .id();

would be better temporary workaround, it behaves well when toggling, but not when resizing

from bevy.

Agree that this is another instance of #13155

I thought perhaps the fact that I was not setting a height and relying on the content to expand that node might have been be the issue. Setting min height in the styles did not help though.

Hmm... this was also my understanding of the issue.

EDIT: Ok, I've found another issue that may have caused the min-width to be ignored. #13555 is up that should hopefully fix both issues.

from bevy.

Thanks everyone for their support. Given that the linked issue is very active and the suggested temporary workaround, I will close this and pay attention to #13555. Once 0.14 is released, assuming the fix will be included, I will test this again and reopen in case I observe the behavior.

from bevy.

@bugsweeper Maybe open a new issue tracking the viewport updating issue

from bevy.

Sounds like a system ordering issue if it's occurring irregularly.

from bevy.

I thought perhaps the fact that I was not setting a height and relying on the content to expand that node might have been be the issue. Setting min height in the styles did not help though.

Also changing pretty much any Styles property triggers reevaluation and sets the Transform component to its correct value.

What's a good way for me to provide more information? I tried RUST_LOG=bevy_ui=trace but this yields not logs.

from bevy.

The culprit seems to be the WorldInspectorPlugin. If I don't add it, I am unable to reproduce the issue after many runs. With it, it's that 1/5 chance.

Now, it's unclear whether merely adding some extra systems increases the odds of this happening due to, as you pointed out, some specific ordering condition, or whether the plugin directly breaks something that bevy_ui calculations rely on.

from bevy.

@porkbrain Looks like as in #13155 there is a problem in bevy_ui (or rather in taffy api), when there is only one dimension (width or height) is set with PositionType::Absolute. As workaround you can add height: Val::Px(384.0) in root Style instance, then behavour of your UI becomes much more stable. At least, I am unable to reproduce the issue with this change.

from bevy.

This workaround is not perfect. The issue is much more rare, but still exists even with it.
I think we should compare more info from root's data
Correct values

Uncorrect values

I think that the most valuable is Node::calculated_size.

from bevy.

Some experimenting I did a while back is that the resolution sometimes gets set to 0, 0 when minimized and under other certain conditions depending on the platform. But I don't understand why that would stick rather than get updated here.

I would probably check if the window's physical resolution matches the camera's computed target info, my guess is there is a chain here where it misses an update about this.

from bevy.

why that would stick rather than get updated here

Looks like camera fixes it's resolution later, but taffy still continues to store zeros in layout despite being given the correct data at step 2

when minimized and under other certain conditions depending on the platform

My reproducing flow is restarting app from reproduce instructions until problem occurs (determine unsuccessfull launch), then I can repeat problem again just by toggling nodes without app restart.

from bevy.

Update:

why that would stick rather than get updated here

The reason is that compute_camera_layout() updates resolution in root_nodes.implicit_viewport_node which containes node for viewport (this is correct, because available_space relates to viewport), but then update_uinode_geometry_recursive() updates geometry starting from user ui root node which is just a child of viewport node. So user ui root node doesn't update according to updated camera.size. @bardt, please tell us, shouldn't camera.root_nodes contain node of viewport instead of ui root node?

from bevy.

@alice-i-cecile I think we should reopen this issue again, I left additional info in previous comment about reason why this issue wants another PR.
My plan is to migrate reproducing example to 0.14.0-dev (main) and to be abble check future fix, because before now I debugged 0.13.2 version

from bevy.

@alice-i-cecile I did migrate example to bevy main (with #13555 fix) and example became much more stable (I ran ~30 times example to reproduce bug), but bug still persist. I will make fix PR according to syncing viewport and root ui node

from bevy.