de04af8fb7
## Symptom Fix this long-standing, occasional bug, that can cause text to look compressed and "drunk": <img width="552" height="226" alt="Screenshot 2026-06-22 at 13 12 56" src="https://github.com/user-attachments/assets/9b1abad4-5ef6-4771-8168-f201afc341ab" /> ## Root cause `epaint::TextureAtlas::take_delta` is fire-and-forget: it resets the dirty region as soon as it hands out a delta, assuming the delta will be uploaded. Atlas growth always emits a **full** `ImageDelta` (`pos: None`) which recreates the GPU texture at the new size — *as long as it is applied*. But both native integrations applied `textures_delta` inside skippable code paths: - **wgpu** (`egui-wgpu/src/winit.rs`): textures were uploaded only *after* surface-dependent early-returns (`render_state` / `surfaces.get_mut(viewport_id)` missing). Texture uploads are device-level and don't need a surface. - **glow** (`eframe/src/native/glow_integration.rs`): textures were uploaded only inside `if is_visible { … }` (and after a viewport-missing early-return), while `integration.update` still ran and grew the atlas. The root window even starts hidden on purpose (`with_visible(false)`, to avoid a startup white flash), so the very first frames hit this. When the delta was dropped, the GPU font texture stayed smaller than the CPU-side atlas; every glyph UV (normalized by the CPU atlas size) then sampled the wrong rows until the next full atlas recreation. wgpu/Metal can't detect this — the read is in-bounds, just the wrong row. ## Fixes - **wgpu**: apply `textures_delta.set` right after `render_state` is obtained, **before** any surface-dependent early-return. `free` still runs after submit (unchanged). - **glow**: apply `textures_delta.set` (and `free`) regardless of `is_visible`, making the GL context current when there's anything to upload; only tessellation/paint/swap stay gated on visibility. - **debug assert** in `egui-wgpu`'s `Renderer::update_texture`: a full delta must (re)create the GPU texture at exactly the delta size — catches any future CPU/GPU size desync at the source. ## wgpu ruled out Confirmed the desync is **not** inside wgpu: Metal `create_texture` uses the exact descriptor size, and `queue.write_texture` validates against the texture's own live `desc` — a single texture can't have CPU/GPU sizes disagree. The mismatch is born at the egui boundary (atlas size for UVs vs. last-applied upload), which wgpu cannot see. ## Testing note A headless regression test of `paint_and_update_textures` isn't practical (it needs a real winit window; `render_state` is private with no surface-less setter). I verified the failure *mechanism* separately on macOS/Metal (texture lagging the atlas → silent wrong-row sampling, no wgpu error), but that demo did not exercise the fixed code path, so it's not included. The fixes rest on the reasoning above. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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).