Sliced images not working with BackgroundColor when using limited features enabled.

[eckz]

Bevy version

Bevy 0.16

Relevant system information

Cargo version:
cargo 1.87.0 (99624be96 2025-05-06)

Adapter Info:
AdapterInfo { name: "Apple M1 Pro", vendor: 0, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Metal }

What you did

Two things are needed to trigger this issue:

• Having a sliced image (NodeImageMode::Sliced) together with a BackgroundColor
• Run the code with limited features enabled. (std,bevy_ui,bevy_text,png,bevy_winit)

What went wrong

Using ui_texture_atlas_slice as a base. If the example is modified adding a BackgroundColor(Color::srgba(1.0, 0.0, 0.0, 0.9)) to the sliced images:

@@ -100,6 +100,7 @@ fn setup(
                             margin: UiRect::all(Val::Px(20.0)),
                             ..default()
                         },
+                        BackgroundColor(Color::srgba(1.0, 0.0, 0.0, 0.9)),
                     ))
                     .with_children(|parent| {
                         parent.spawn((

I would expect the sliced images to be printed in top of the background color.

If I run the modified example with

cargo run --example ui_texture_atlas_slice --no-default-features --features std,bevy_ui,bevy_text,png,bevy_winit

This is what I get

But running the modified example with bevy_gizmos enabled

cargo run --example ui_texture_atlas_slice --no-default-features --features std,bevy_ui,bevy_text,png,bevy_winit,bevy_gizmos

Shows the correct behaviour

Additional information

• I'm not sure why enabling bevy_gizmos fix the issue, but the code does not depends on that, it seems like enabling it adds the correct order of drawing things.
• The issue seems to be stable in the sense that it either never works or it works all the time, it doesn't seem to be random.
• I found about the issue in a different project, but the modified example is the best way to reproduce it.

[ickshonpe]

I see what's wrong. The UI depth sort is stable and they are both given the same z depth so the ordering is determined by whichever system runs first: queue_uinodes or queue_ui_slices.