[REGRESSION] macOS/metal window resize from top causes hangs

[krisdigital]

Describe the bug
I upgraded from 0.29 to 0.34 both using wgpu and noticed that resizing the top of the window causes hangs after the upgrade. I checked with a minimal app and the latest egui from the main branch - it depends on the window width and if resizing from the bottom (is smooth) or from the top (choppy).

Code I used to test:

use eframe::Frame;

use eframe::egui::{self};

struct App {}

impl App {
    fn new(_cc: &eframe::CreationContext) -> Self {
        App {}
    }
}

impl eframe::App for App {
    //fn update(&mut self, ctx: &egui::Context, frame: &mut eframe::Frame) {}
    fn ui(&mut self, ui: &mut egui::Ui, _frame: &mut Frame) {
        ui.label("Hello");
    }
}

fn main() -> eframe::Result {
    let options = eframe::NativeOptions {
        persist_window: false,
        viewport: egui::ViewportBuilder::default().with_inner_size([800.0, 600.0]),
        renderer: eframe::Renderer::Wgpu,
        ..Default::default()
    };
    eframe::run_native(
        "egui-test",
        options,
        Box::new(|cc| Ok(Box::new(App::new(cc)))),
    )
}

To Reproduce
Steps to reproduce the behavior:

1. Open a minimal app on macOS
2. Resize the window to be full width
3. Grab the upper side and resize
4. Experience choppiness

Expected behavior
With 0.29 I could see that resize caused a little white flicker at the top, but otherwise it was smooth.

Screenshots

0.34

0_34_hang.mov

0.29

0_29_no_hang.mp4

Desktop (please complete the following information):

• OS: macOS, M1/Metal
• Version 15.7.4

Additional context
I tried profiling, I see the hangs in the profiler but I have no idea what could be the reason...

[smoe]

We are seeing what looks like the same regression family on macOS [Tahoe 26.4] after upgrading from the 0.33.x line to 0.34.1, although our visible symptom differs from the original report.

In our case the failure is specifically tied to native child viewports:

• egui::Window embedded in the root UI is stable
• Context::show_viewport_immediate(...) reproduces the bug
• Context::show_viewport_deferred(...) also reproduces the bug

We reduced this to a minimal app with:

• one root window
• a small animated surface
• a button opening a child window
• each child window can render the same content and optionally open another child

Exact reproduction pattern on macOS

1. start the app
2. the first window looks normal
3. the first window can be maximized and restored normally
4. open a second native child window
5. now maximize the first window

At that point, the bug starts:

• a flicker appears involving the second window
• the second window, which should remain hidden behind the first, briefly surfaces
• it is then forced back behind the apparently repainted maximized first window
• then it reappears again, and this repeats

If instead the second-opened window is the one being maximized:

• it jumps back to its previous size instead of staying maximized
• a stale copy of the window can then be seen when the window is moved

Reduction results on macOS

• reproduces with both immediate and deferred native child viewports
• still reproduces with animation disabled
• still reproduces with no initial cascade positioning
• still reproduces without nested-child spawning
• does not reproduce when child viewports are forced into embedded windows

So this appears to be tied to native child viewport lifecycle / window recreation on macOS rather than application-specific layout logic.

Looking through the current code, one suspicious path is:

• eframe/src/native/wgpu_integration.rs
• initialize_or_update_viewport(...)
• viewport.builder.patch(builder)

If patch(...) returns recreate = true, the code explicitly drops the existing native window:

viewport.window = None;
viewport.egui_winit = None;
painter.set_window(viewport.ids.this, None)

and then rebuilds it.

That recreation path matches our observed stale/new window behavior quite closely, although we have not yet identified the exact ViewportBuilder delta that triggers it during macOS resize/maximize.

For now our workaround on macOS is:

ctx.set_embed_viewports(true);
which avoids the failure by forcing the embedded-window path, but obviously changes the UX.

For reference, our last coherent pre-upgrade stack:

eframe 0.33.3
egui 0.33.3
egui_extras 0.33.3

did not exhibit this behavior in the same application structure.

If useful, I can share the minimal repro source.

[smoe]

I just compiled the same app on Windows and could not reproduce that problem.

[krisdigital]

I did a check with 0.33 - everything is fine! So it must have happened in the latest version 🕵️‍♂️

[yay]

I had to downgrade to 0.33 because with 0.34 the resize was unusable on macOS 15.7.4 (very laggy and choppy, like 1-3 FPS), despite the UI CPU time still being under 4ms, just like with 0.33.

The big spikes were in Surface::get_current_texture() during the resize. Up to 1000+ ms in the worst case.

Switching to PresentMode::Immediate and setting desired_maximum_frame_latency = 2 (I normally use 1) helped, somewhat.

But disabling the macOS resize transaction path (CAMetalLayer.presentsWithTransaction) in the egui-wgpu resize handling helped a lot more. Though there was still some minor choppiness, even thought the overall frame rate went back to normal.

[krisdigital]

I think it might be this change of defaults for egui-wgpu: 0.34.0...0.33.3#diff-36ab42f64ac7547e27e7376ad19fae03fc5d864168543e217870b70235fe0ba4R28

I removed the feature flag "macos-window-resize-jitter-fix" on egui-wgpu using these dependencies

eframe = { version = "0.34", default-features = false, features = ["wgpu_no_default_features", "persistence"] }
wgpu = { version = "*", features = ["metal"] } 
egui-wgpu = { version = "0.34", default-features = false }

and the choppiness is gone 🥳