Randomly sprite does not render and systems do not function

[Frost2779]

Bevy version

Reproducible on 0.14.2, 0.15.0-rc1, and main.

[Optional] Relevant system information

Rust: 1.82.0
OS: Nobara Linux 40

`AdapterInfo { name: "NVIDIA GeForce RTX 2070 SUPER", vendor: 4318, device: 7812, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "560.35.03", backend: Vulkan }`

I have tested on upstream wgpu and experiences no rendering issues.

What you did

I created a simple project with only the most recent release of bevy as the dependency. I setup the project as needed for what I am trying to accomplish. That being getting a sprite to render to the screen, be able to move around the screen using the middle mouse button, and then use the scroll wheel to be able to zoom in/out.

Upon running the project, I received the following output:

What went wrong

Sometimes, it seems like the sprite doesn't render, and other times, the sprite renders, but the systems seem not to function as expected, seeming to do nothing. Various println have confirmed that the systems are in fact running, and handle proper mouse input, but seem to have no effect. This usually required me to run the app a few times before both the sprite renders and the systems function. Furthermore, even if the mouse systems section is removed, the issue with the sprite randomly not rendering still persists.

• what were you expecting?
  The sprite would render and the systems would function consistently.

MRE of the project code:

use bevy::{input::{common_conditions::input_pressed, mouse::{MouseMotion, MouseWheel}}, prelude::*};

#[derive(Component)]
struct MainCamera;

fn main() {
    App::new()
        .add_plugins(
            DefaultPlugins
                .set(ImagePlugin::default_nearest())
        )
        .add_systems(Startup, setup)
        .add_systems(Update, (
            mouse_zoom, 
            mouse_pan.run_if(input_pressed(MouseButton::Middle))
        ))
        .run();
}

fn setup(mut commands: Commands, server: Res<AssetServer>) {
    commands.spawn((Camera2d::default(), MainCamera));
    commands.spawn(Sprite{
        image: server.load("placeholder.png"),
        ..default()
    });
}

fn mouse_zoom(
    mut scroll_events: EventReader<MouseWheel>,
    mut query_camera: Query<&mut OrthographicProjection>
) {
    let mut projection = query_camera.single_mut();
    for ev in scroll_events.read() {
        if ev.y > 0. {
            projection.scale /= 1.25;
        } else if ev.y < 0. {
            projection.scale *= 1.25;
        }
    }
}

fn mouse_pan(
    mut evr_motion: EventReader<MouseMotion>,
    mut q_transform: Query<&mut Transform, With<MainCamera>>
) {
    let mut transform = q_transform.single_mut();
    for ev in evr_motion.read() {
        transform.translation.x += ev.delta.x * -1.;
        transform.translation.y += ev.delta.y;
    }
}

Additional information

I believe that the error that I am seeing related to EGL 'eglCreateSyncKHR' can likely be ignored as I see the same error as part of testing wgpu and didn't not experience any rendering difficulties there across multiple examples runs.

[alice-i-cecile]

The specific pattern of behavior (differing behavior across different runs) makes me suspect that this is due to a rendering-related system order ambiguity. The broad category is tracked in #7386.

[Frost2779]

Is there any kind of override I could provide on my end in the meantime to force a more specific order to combat this problem, or will it need to be fixed upsteam?

[alice-i-cecile]

If you can figure out what the problem is, you should be able to patch it in your project by adding a dependency between the offending system sets. That's more a backporting strategy than a proper workaround though, and if you do end up figuring out what pair is causing this problem, please do let us know and/or submit a patch.

[Frost2779]

However, would this rendering ambiguity also be responsible for the systems seeming not to function since they were related to transforming what was rendered?

[alice-i-cecile]

Probably not; I'm really not sure what's going on there.

[bas-ie]

Just to add a data point: can't reproduce on Wayland/AMD card. I'm always suspicious of NVIDIA linux drivers, but you'd think a GeForce RTX 2070 SUPER would be pretty well-supported by now! @Frost2779, if you were interested in a little experimentation, you could try swapping from the proprietary NVIDIA driver to nouveau to see if the problem goes away. Might add a little information to the issue 🤔

[eero-lehtinen]

I'm pretty sure this is a xwayland + nvidia issue. Basically the window is frozen and the game is otherwise running just fine. It happens to me too and can be fixed by resizing the window after startup or enabling the wayland feature.

Maybe we could rethink the Couldn't get swap chain texture. This often happens with the NVIDIA drivers on Linux. It can be safely ignored. error to somehow force update the window on startup. It seems that it infact can't be safely ignored.

[Frost2779]

Yea I can confirm that @eero-lehtinen's workaround of enabling the wayland feature solved this for me. I can't recreate the original issue after enabling.

[alice-i-cecile]

I'm going to call this "upstream's bug" and close it out :(

[eero-lehtinen]

There might be something we can do. I experimented with some changes and I was able to kind of fix this. I just didn't realise this was still an issue because I always have wayland enabled.