a8d09eb60d
## Summary
This fixes macOS live-resize behavior for the `eframe`/`egui-wgpu` path
when using the low-latency wgpu surface configuration.
The problem I was seeing is that native window resize can look visibly
below the baseline expected from a desktop GUI: stale or stretched
frames (manifesting as wobble/jitter), or severe lag while dragging a
window edge.
The fix has three parts:
- use `CAMetalLayer.presentsWithTransaction` during live resize to avoid
stale/stretched frames
- temporarily use at least `desired_maximum_frame_latency = 2` while
live resize is active, so transaction presentation does not stall when
the app normally uses `SurfaceConfig::LOW_LATENCY`
- treat macOS `WindowEvent::Moved` as part of the live-resize event
stream, since resizing from the top or left edge changes the window
origin
This PR depends on the winit-side AppKit live-resize timing fix in
[rust-windowing/winit#4588](https://github.com/rust-windowing/winit/pull/4588)
A renderer-only frame-latency change is not enough by itself. The
temporary latency bump only solves the drawable starvation caused by
combining `presentsWithTransaction` with `SurfaceConfig::LOW_LATENCY`.
It does not change when winit emits resize/redraw events, whether
redraws are delivered during AppKit's live-resize event-tracking loop,
or whether the surface size is derived from the current backing rect.
That is why the winit fix is needed first: it makes the windowing layer
report the current AppKit backing size and request redraws from the
live-resize/display callbacks. egui-wgpu still needs this PR on top
because winit does not own the wgpu `Surface` or the underlying
`CAMetalLayer` presentation policy.
In other words: winit fixes when the windowing layer reports
resize/redraw work, while this PR fixes how egui-wgpu presents
Metal-backed wgpu frames during that resize.
## Why change the existing feature?
The existing `macos-window-resize-jitter-fix` feature addresses one
symptom by enabling transaction presentation during resize, but it is
not enough for the low-latency wgpu path.
In particular, `presentsWithTransaction` and
`SurfaceConfig::LOW_LATENCY` interact poorly during AppKit live resize.
The old code avoids that by [skipping transaction presentation when
latency is
`1`](71c4ff3c33/crates/egui-wgpu/src/winit.rs (L417)),
but that means low-latency users get the resize jitter/wobble back.
This PR keeps the low-latency path normally, but temporarily bumps frame
latency only while live resize is active. That gives the resize path
enough drawable slack without changing normal interaction latency.
I removed the `macos-window-resize-jitter-fix` feature because this
seems like the behavior the macOS wgpu path should have by default, not
a separate opt-in. If keeping the feature as a no-op compatibility alias
is preferred, I can adjust the PR.
## Validation
I created a small demo app that somewhat resembles the layout of my
actual app and highlights both horizontal and vertical resize jitter:
- a borderless macOS window
- a simple toolbar
- a scrolling side list
- `SurfaceConfig::LOW_LATENCY`
The toolbar and list make stale or stretched frames easy to see during
native resize. The jitter is visible even on the traffic light buttons.
Recordings:
### Before 1: no transaction presentation, low latency
Shows jitter/wobble and stale/stretched frames during live resize.
https://github.com/user-attachments/assets/2cf4467b-e14c-4f41-8021-0b8c23f41004
### Before 2: transaction presentation with low latency
Shows the other failure mode: live resize can become severely laggy when
transaction presentation is used while keeping
`SurfaceConfig::LOW_LATENCY`.
https://github.com/user-attachments/assets/2f866790-f472-4ede-a3c0-480e8f0f041a
### After: patched egui-wgpu + patched winit, low latency
No visible wobble/jitter and no severe live-resize lag.
https://github.com/user-attachments/assets/59e46e9f-7906-4b5c-a6c7-1d09eae644cd
---------
Co-authored-by: lucasmerlin <hi@lucasmerlin.me>
eframe: the egui framework
eframe is the official framework library for writing apps using egui. The app can be compiled both to run natively (for Linux, Mac, Windows, and Android) or as a web app (using Wasm).
To get started, see the examples.
To learn how to set up eframe for web and native, go to https://github.com/emilk/eframe_template/ and follow the instructions there!
There is also a tutorial video at https://www.youtube.com/watch?v=NtUkr_z7l84.
For how to use egui, see the egui docs.
eframe defaults to using wgpu for rendering (with an option to change to glow), and on native it uses egui-winit.
To use on Linux, first run:
sudo apt-get install libxcb-render0-dev libxcb-shape0-dev libxcb-xfixes0-dev libxkbcommon-dev libssl-dev
You need to either use edition = "2024", or set resolver = "2" in the [workspace] section of your to-level Cargo.toml. See this link for more info.
You can opt-in to the using egui_glow for rendering by enabling the glow feature and setting NativeOptions::renderer to Renderer::Glow.
Alternatives
eframe is not the only way to write an app using egui! You can also try egui-miniquad, bevy_egui, egui_sdl2_gl, and others.
You can also use egui_glow and winit to build your own app as demonstrated in https://github.com/emilk/egui/blob/main/crates/egui_glow/examples/pure_glow.rs.
Limitations when running egui on the web
eframe and egui compiles to Wasm using either WebGPU (when available) or WebGL2 for rendering, and almost nothing else from the web tech stack. This has some benefits, but also produces some challenges and serious downsides.
- Rendering: Getting pixel-perfect rendering right on the web is very difficult.
- Search: you cannot search an egui web page like you would a normal web page.
- Bringing up an on-screen keyboard on mobile: there is no JS function to do this, so
eframefakes it by adding some invisible DOM elements. It doesn't always work. - Mobile text editing is not as good as for a normal web app.
- No integration with browser settings for colors and fonts.
- Accessibility: There is an experimental screen reader for
eframe, but it has to be enabled explicitly. There is no JS function to ask "Does the user want a screen reader?" (and there should probably not be such a function, due to user tracking/integrity concerns).eguisupports AccessKit, but as of early 2024, AccessKit lacks a Web backend.
In many ways, eframe is trying to make the browser do something it wasn't designed to do (though there are many things browser vendors could do to improve how well libraries like egui work).
The suggested use for eframe are for web apps where performance and responsiveness are more important than accessibility and mobile text editing.
Companion crates
Not all rust crates work when compiled to Wasm, but here are some useful crates have been designed to work well both natively and as Wasm:
Name
The frame in eframe stands both for the frame in which your egui app resides and also for "framework" (eframe is a framework, egui is a library).