Shluggish window resize with 3D content

[StefanSalewski]

Bevy version: 0.17.2

• Original: 0.16.1
• Current: latest 0.17.2

Relevant system information

Please include:

• the Rust version: cargo 1.90.0 (840b83a10 2025-07-30) (gentoo)
• the operating system: Gentoo Linux for AMD64, Gnome with Wayland

What's performing poorly?

My Bevy 3D Chess GUI -- Bevy examples show a similar behaviour
Currently my old Chess working with Bevy 0.16.1 is still available
at GitHub and works fine: https://github.com/StefanSalewski/Bevy-3D-Chess

My local port to Bevy 0.17.2 is very sluggish when window is resized.

I just tested with

cargo run --example simple_picking.rs

That examples is also sluggish and has some delay when its window is resized, but due to the simple content the effect is not that significant.

[StefanSalewski]

The example ./picking/mesh_picking.rs is also sluggish when grabbing the lower right corner for resizing.

But other examples like motion_blur.rs work fine. So I would guess that there is something wrong with the picking support.

[StefanSalewski]

Actually

cargo run --example motion_blur

behaves fine when window is resized,

while the simple

cargo run --example 3d_scene

is sluggish.

And what is interesting: 3d_scene.rs behaves very sluggish when the window is small, but fine when the window is very large. I would have expected the opposite.

[HugoPeters1024]

Could you try if the issue is also present in release mode by adding --release to the cargo command? There is reasonable chance that the shlugginess is caused by Vulkan validation layers, which are usually disabled in release mode.

[StefanSalewski]

For my chess GUI it is the same in release mode, I just tried with

cargo run --release

And the observation is again, that the effect is very strong when the GUI window is small, but much less when the window is large.

For

cargo run --release --example 3d_scene

I get the output

   Compiling bevy v0.18.0-dev (/home/stefan/bevy)
    Finished `release` profile [optimized] target(s) in 4m 06s
     Running `target/release/examples/3d_scene`
2025-11-08T22:50:49.191589Z  INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "Linux (Gentoo 2.18)", kernel: "6.17.6", cpu: "AMD Ryzen 9 5900HX with Radeon Graphics", core_count: "8", memory: "62.2 GiB" }
2025-11-08T22:50:49.214609Z  INFO bevy_render::renderer: AdapterInfo { name: "AMD Radeon Graphics (RADV RENOIR)", vendor: 4098, device: 5688, device_type: IntegratedGpu, driver: "radv", driver_info: "Mesa 25.1.9", backend: Vulkan }
2025-11-08T22:50:49.256413Z  INFO bevy_render::batching::gpu_preprocessing: GPU preprocessing is fully supported on this device.
2025-11-08T22:50:49.258472Z  INFO bevy_winit::system: Creating new window 3d_scene (0v0)
2025-11-08T22:51:17.232818Z  INFO bevy_window::system: No windows are open, exiting
2025-11-08T22:51:17.233235Z  INFO bevy_winit::system: Closing window 0v0

and the window resizing is again very sluggish with a delay of one to two seconds. Looks like the mouse positions of lower right window edge (that determines new size) are queued and processed slowly with a lot of delay.

[HugoPeters1024]

Okay thanks for confirming that! I currently cannot reproduce this on MacOS. The next step in narrowing this down is bisecting the git history to figure out which exact commit caused this regression. In case you are not familiar with that process, let me give you some pointers: https://git-scm.com/docs/git-bisect.

The main idea is that you mark the latest commit as bad, and whatever commit is 1.16.1 as good. Git will then help you binary search all the commits in between by repeatedly asking you if the current commit has the problem or not (I'm afraid manually testing each time is the only realistic option here).

With those results in hand it should be a lot easier to figure out who are what is to blame for this regression :)

[StefanSalewski]

OK, I will try. My current problem following your linked documentation is, that after

git bisect good v0.16.1

cargo run --example 3d_scene

fails to compile with errors like

   Compiling smol-macros v0.1.1
   Compiling ureq v3.1.4
   Compiling argh v0.1.13
error: implicit autoref creates a reference to the dereference of a raw pointer
   --> crates/bevy_mikktspace/src/generated.rs:759:25
    |
759 |         bStillSame = if (*pg1).pTriMembers[i] == (*pg2).pTriMembers[i] {
    |                         ^^---^^^^^^^^^^^^^^^^
    |                           |
    |                           this raw pointer has type `*const SSubGroup`
    |
    = note: creating a reference requires the pointer target to be valid and imposes aliasing requirements
note: autoref is being applied to this expression, resulting in: `&Vec<i32>`
   --> crates/bevy_mikktspace/src/generated.rs:759:25
    |
759 |         bStillSame = if (*pg1).pTriMembers[i] == (*pg2).pTriMembers[i] {
    |                         ^^^^^^^^^^^^^^^^^^
    = note: `#[deny(dangerous_implicit_autorefs)]` on by default
help: try using a raw pointer method instead; or if this reference is intentional, make it explicit
    |
759 |         bStillSame = if (&(*pg1).pTriMembers)[i] == (*pg2).pTriMembers[i] {
    |                         ++                  +

error: implicit autoref creates a reference to the dereference of a raw pointer
   --> crates/bevy_mikktspace/src/generated.rs:759:50
    |
759 |         bStillSame = if (*pg1).pTriMembers[i] == (*pg2).pTriMembers[i] {
    |                                                  ^^---^^^^^^^^^^^^^^^^
    |                                                    |
    |                                                    this raw pointer has type `*const SSubGroup`
    |
    = note: creating a reference requires the pointer target to be valid and imposes aliasing requirements
note: autoref is being applied to this expression, resulting in: `&Vec<i32>`
   --> crates/bevy_mikktspace/src/generated.rs:759:50
    |
759 |         bStillSame = if (*pg1).pTriMembers[i] == (*pg2).pTriMembers[i] {
    |                                                  ^^^^^^^^^^^^^^^^^^
help: try using a raw pointer method instead; or if this reference is intentional, make it explicit
    |
759 |         bStillSame = if (*pg1).pTriMembers[i] == (&(*pg2).pTriMembers)[i] {
    |                                                  ++                  +

error: could not compile `bevy_mikktspace` (lib) due to 2 previous errors

I have currently no idea why. My guess would be that my rustc 1.90.0 is not compatible with the old Bevy code. But then I wonder why I can still compile my old chess GUI with Bevy 0.16.1. (Well, perhaps because I shipped no Cargo.lock to github, so Cargo is not forced to use old minor releases of crates when compiling my chess. So I will try starting bisec with 0.17.0, maybe that will compile.)

[StefanSalewski]

:-(

Bevy 0.17.0 compiles but is sluggish with delay. So the problem must have been introduced between v0.16.1 and v0.17.0. Actually that was expected.