-
-
Notifications
You must be signed in to change notification settings - Fork 4k
Closed
Labels
A-RenderingDrawing game state to the screenDrawing game state to the screenA-UIGraphical user interfaces, styles, layouts, and widgetsGraphical user interfaces, styles, layouts, and widgetsC-BugAn unexpected or incorrect behaviorAn unexpected or incorrect behaviorS-Needs-InvestigationThis issue requires detective work to figure out what's going wrongThis issue requires detective work to figure out what's going wrong
Description
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 aBackgroundColor
- 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
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.
Metadata
Metadata
Assignees
Labels
A-RenderingDrawing game state to the screenDrawing game state to the screenA-UIGraphical user interfaces, styles, layouts, and widgetsGraphical user interfaces, styles, layouts, and widgetsC-BugAn unexpected or incorrect behaviorAn unexpected or incorrect behaviorS-Needs-InvestigationThis issue requires detective work to figure out what's going wrongThis issue requires detective work to figure out what's going wrong
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
ickshonpe commentedon Jun 17, 2025
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
orqueue_ui_slices
.UI z-ordering fix (#19691)