Window resizing can freeze up rendering.

[IQuick143]

Bevy version

• 0.16
• 0.17-dev (git+https://github.com/bevyengine/bevy.git#657f71b6e6880746ed09dcdea5dacad118dfc87e)

[Optional] Relevant system information

Void Linux + X.Org + Nvidia drivers + KDE

`AdapterInfo { name: "NVIDIA GeForce RTX 3050 Laptop GPU", vendor: 4318, device: 9634, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "580.76.05", backend: Vulkan }`

What you did

Run the following code:

use bevy::prelude::*;

fn main() {
	App::new()
	.add_plugins(DefaultPlugins)
	.run();
}

with the following dependencies:

[dependencies]
bevy = { git = "https://github.com/bevyengine/bevy.git", default-features=false, features = [
    "bevy_asset",
    "bevy_log",
    "bevy_render",
    "bevy_window",
    "x11",
] }

or use version = 0.16.0
(x11, bevy_asset, bevy_window are needed to make the project compile, bevy_render is needed to trigger the bug, bevy_log for diagnostics)

What went wrong

Resizing the window causes the following warning:

2025-09-10T13:09:13.732393Z  WARN bevy_render::view::window: Couldn't get swap chain texture after configuring. Cause: 'The underlying surface has changed, and therefore the swap chain must be updated'

This is not a problem by itself, the project keeps working.
However by sufficiently fiddling with the window size (low mouse sensitivity seems to help trigger it, but that's just a feeling) the following may happen:

1. GPU usage rises considerably (not an issue necessarily, but might be relevant)
2. The entire graphical session hangs for a few seconds, this might be a stability issue on my part, not bevy.
3. The game enters a state where the swapchain is completely invalid. This has the two following effects:
   a) The warning is emitted every frame:

2025-09-10T13:09:13.546944Z  WARN bevy_render::view::window: Couldn't get swap chain texture after configuring. Cause: 'The underlying surface has changed, and therefore the swap chain must be updated'
2025-09-10T13:09:13.573010Z  WARN bevy_render::view::window: Couldn't get swap chain texture after configuring. Cause: 'The underlying surface has changed, and therefore the swap chain must be updated'
2025-09-10T13:09:13.599742Z  WARN bevy_render::view::window: Couldn't get swap chain texture after configuring. Cause: 'The underlying surface has changed, and therefore the swap chain must be updated'
2025-09-10T13:09:13.625975Z  WARN bevy_render::view::window: Couldn't get swap chain texture after configuring. Cause: 'The underlying surface has changed, and therefore the swap chain must be updated'

b) The binary no longer renders any new frames, appearing "frozen" and glitched.

Resizing the window again re-rolls the bug, usually avoiding it, but sometimes triggering it again.

Additional notes

I'm not sure if this can be reproduced on Windows or Mac, also would need testing on Wayland probably.

[it-me-joda]

I am unable to reproduce on my system

2025-09-10T15:32:32.602284Z  INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "Linux (EndeavourOS rolling)", kernel: "6.16.5-arch1-1", cpu: "AMD Ryzen 7 3700X 8-Core Processor", core_count: "8", memory: "62.7 GiB" }
2025-09-10T15:32:32.654728Z  INFO bevy_render::renderer: AdapterInfo { name: "AMD Radeon RX 6950 XT (RADV NAVI21)", vendor: 4098, device: 29605, device_type: DiscreteGpu, driver: "radv", driver_info: "Mesa 25.2.2-arch1.2", backend: Vulkan }

I used the following to attempt to reproduce on 0.16

use std::f32::consts::TAU;

use bevy::prelude::*;

fn main() {
    App::new()
        .add_plugins(DefaultPlugins.set(WindowPlugin {
            primary_window: Some(Window {
                mode: bevy::window::WindowMode::Windowed,
                ..default()
            }),
            ..default()
        }))
        .add_systems(Startup, startup)
        .add_systems(Update, update)
        .run();
}

fn startup(
    mut commands: Commands,
    mut meshes: ResMut<Assets<Mesh>>,
    mut materials: ResMut<Assets<StandardMaterial>>,
) {
    commands.spawn((
        Camera3d::default(),
        Transform::from_xyz(-4.5, 2.5, 4.5).looking_at(Vec3::ZERO, Vec3::Y),
    ));

    commands.spawn((
        Mesh3d(meshes.add(Cuboid::new(1.0, 1.0, 1.0))),
        MeshMaterial3d(materials.add(Color::WHITE)),
        Transform::from_xyz(0.0, 0.0, 0.0),
    ));
}

fn update(mut cuboid: Single<&mut Transform, With<Mesh3d>>, timer: Res<Time>) {
    let mut transform = cuboid;
    transform.rotate_y(TAU * timer.delta_secs() * 0.5);
}

Let me know if I can help try to reproduce this in a different way.

[IQuick143]

Do you get the warning at all (but can't reproduce the frozen state) or does the warning not happen at all?

[IQuick143]

I managed to reproduce the bug with your setup.

[stillbeingnick]

So while I was not able to directly reproduce the decline in performance, I did observe some interesting things happening during testing the code snippet above from @it-me-joda. That were also present in the bare-bones code snippet in the issue outline.

Test system specs:

OS: Arch Linux x86_64, Kernel: 6.16.1-arch1-1, DE: Plasma 6.4.4, WM: kwin

2025-09-11T01:06:27.841564Z  INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "Linux (Arch Linux rolling)", kernel: "6.16.1-arch1-1", cpu: "AMD Ryzen 9 7950X3D 16-Core Processor", core_count: "16", memory: "124.9 GiB" }
2025-09-11T01:06:27.993896Z  INFO bevy_render::renderer: AdapterInfo { name: "NVIDIA GeForce RTX 4090", vendor: 4318, device: 9860, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "580.76.05", backend: Vulkan }

There is a freeze when the swap chain is recreated during the window being resized, which is to be expected. I do get the warning that was reported:

2025-09-11T01:16:53.092460Z  WARN bevy_render::view::window: Couldn't get swap chain texture after configuring. Cause: 'The underlying surface has changed, and therefore the swap chain must be updated'

This warning will spawn every frame while the window is resized during which the swap chain is lost and recreated. Which does cause some memory ballooning, I think is related to the logs being created.

There is some odd interaction at least on my machine that Kwin_wayland spikes my gpu usage to ~40% sometimes as high as 70%, then it spikes the usage for the test app. So I wonder if there is some interaction on your machine that is overloading memory or overloading the gpu. Resizing the window will trigger this trade of gpu usage between the window manager and the bevy app for me. It for sure is related to the swap chain in some way and I have a hunch it also involves the DE+WM.

I can see the things that are being reported but not to the degree that it is for you. I would like to see if someone with similar specs to your machine would have similar results.

But also happy to try other things if you can think of any @IQuick143 !

[IQuick143]

The GPU usage spikes you report seem to be in line with the numbers I saw on my device (I just used nvtop).
I don't think that it's VRAM that's getting overloaded, as the VRAM usage stats stay stable (unlike the compute which spikes).

You're right this could be a DE+WM interaction, might be useful to know how it works on other combinations.

[it-me-joda]

Do you get the warning at all (but can't reproduce the frozen state) or does the warning not happen at all?

No I did not receive the warning. I couldn't find a way to trigger any shenanigans on my system. I might try something again in a bit.

I have had some strange things happen on my Hyprland setup but this isn't one of them.

[IQuick143]

Thanks for the info.

[stillbeingnick]

So Windows 11 on the same machine running the same example using bevy 0.16 doesn't throw any warnings at all while resizing so it seems to be a KDE issue? I just don't know what in KDE that causes the weirdness.

[mamekoro]

I often see that warning and I can reproduce it with Bevy 0.16.1 + Ubuntu 24.04 + GNOME + X11 + NVIDIA GPU & driver.

In the code shown by OP, it took several seconds to tens of seconds of continuously resizing the window to reproduce the warning.

Using Bevy with default features (cargo add bevy) caused the warning to appear immediately upon resizing the window.