* closes https://github.com/emilk/egui/issues/5674
This changes egui to create an AccessKit node for each `Ui`. I'm not
sure if this alone will directly improve accessibility, but it should
make it easier to create the correct parent / child relations (e.g.
grouping menus as children of menu buttons).
Instead of having a global stack of parent ids, they are now passed via
a parent_id field in `UiBuilder`.
If having all these `GenericContainer` nodes somehow is bad for
accessibility, the PR could also be changed to only create nodes if
there is actually some accessibility info with it (the relevant is
currently commented-out in the PR). But I think screen readers should
just ignore these nodes, so it should be fine? We could also use this as
motivation to git red of some unnecessary wrapped `Ui`s, e.g.
CentralPanel creates 3 Uis when 2 should be enough (the initial Ui and a
Frame, maybe we could even only show the `Frame` if we can give it an
UiBuilder and somehow show the Frame with `Ui::new`).
Here is a screenshot from the accessibility inspector
(https://github.com/emilk/egui/pull/7368) with this PR:
<img width="431" height="744" alt="Screenshot 2025-07-24 at 12 09 55"
src="https://github.com/user-attachments/assets/6c4e5ff6-5c38-450e-9500-0776c9018d8c"
/>
Without this PR:
https://github.com/user-attachments/assets/270e32fc-9c7a-4dad-8c90-7638c487a602
Adds an accessibility inspector plugin that shows the current AccessKit
tree:
https://github.com/user-attachments/assets/78f4f221-1bd2-4ce4-adf5-fc3b00f5c16c
Macos has a built in accessibility inspector, but it doesn't seem to
work with AccessKit / eframe so this provides some insight into the
accesskit state.
This also showed a couple issues that are easy to fix:
- [ ] Links show up as `Label` instead of links
- [ ] Not all supported actions are advertised (e.g. scrolling)
- [ ] The resize handles in windows shouldn't be focusable
- [ ] Checkbox has no value
- [ ] Menus should have the button as parent widget (not 100% sure on
this one)
Currently the plugin lives in the demo app, but I think it should be
moved somewhere else. Maybe egui_extras?
This could also be relevant for #4650
This PR is a continuation of #4915 by @frederik-uni and @lucasmerlin
that introduces support for keeping egui content within the 'safe area'
on iOS (avoiding the notch / dynamic island / menu bar etc.), with the
following changes:
- `SafeArea` now wraps `MarginF32` and has been renamed to
`SafeAreaInsets` to clarify its purpose.
- `InputState::screen_rect` is now marked as deprecated in favour of
either `viewport_rect` (which contains the entire screen), or
`content_rect` (which is the viewport rect with the safe area insets
removed).
- I added some comments to the safe area insets logic pointing out the
[safe area API coming in winit
v0.31](https://github.com/rust-windowing/winit/issues/3910).
---------
Co-authored-by: frederik-uni <147479464+frederik-uni@users.noreply.github.com>
Co-authored-by: Lucas Meurer <hi@lucasmerlin.me>
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
This adds a new mode, `UPDATE_SNAPSHOTS=force`, which will lower the
threshold to zero, overwriting every image that is not _exactly_ the
same.
Most comparisons has a threshold because different GPUs render slightly
differently. However, setting that threshold accurately can be hard.
Sometimes a test will pass locally, but fail on CI. In those cases you
want to force an update of the failing test. You can use
`UPDATE_SNAPSHOTS=force` for that.
And sometimes a small change _should_ update all images, but the change
is so tiny that it falls under the threshold. Still, you want to make a
point of showing that these images have changes. You can use
`UPDATE_SNAPSHOTS=force` for that.
* related #7494
Removes the `deadlock_detection` feature, since we now have a more
primitive panic-after-30s deadlock detection which works well enough and
even detects kinds of deadlocks that the `deadlock_detection` feature
never supported.
This adds a custom Node struct with proper support for egui types
(`Key`, `Modifiers`, `egui::Event`, `Rect`) instead of needing to use
the kittest / accesskit types.
I also changed the `click` function to do a proper mouse move / mouse
down instead of the accesskit click. Also added `accesskit_click` to
trigger the accesskit event. This resulted in some changed snapshots,
since the elements are now hovered.
Also renamed `press_key` to `key_press` for consistency with
`key_down/key_up`.
Also removed the Deref to the AccessKit Node, to make it clearer when to
expect egui and when to expect accesskit types.
* Closes#5705
* [x] I have followed the instructions in the PR template
Today each widget does its own custom layout, which has some drawbacks:
- not very flexible
- you can add an `Image` to `Button` but it will always be shown on the
left side
- you can't add a `Image` to a e.g. a `SelectableLabel`
- a lot of duplicated code
This PR introduces `Atoms` and `AtomLayout` which abstracts over "widget
content" and layout within widgets, so it'd be possible to add images /
text / custom rendering (for e.g. the checkbox) to any widget.
A simple custom button implementation is now as easy as this:
```rs
pub struct ALButton<'a> {
al: AtomicLayout<'a>,
}
impl<'a> ALButton<'a> {
pub fn new(content: impl IntoAtomics) -> Self {
Self { al: content.into_atomics() }
}
}
impl<'a> Widget for ALButton<'a> {
fn ui(mut self, ui: &mut Ui) -> Response {
let response = ui.ctx().read_response(ui.next_auto_id());
let visuals = response.map_or(&ui.style().visuals.widgets.inactive, |response| {
ui.style().interact(&response)
});
self.al.frame = self
.al
.frame
.inner_margin(ui.style().spacing.button_padding)
.fill(visuals.bg_fill)
.stroke(visuals.bg_stroke)
.corner_radius(visuals.corner_radius);
self.al.show(ui)
}
}
```
The initial implementation only does very basic layout, just enough to
be able to implement most current egui widgets, so:
- only horizontal layout
- everything is centered
- a single item may grow/shrink based on the available space
- everything can be contained in a Frame
There is a trait `IntoAtoms` that conveniently allows you to construct
`Atoms` from a tuple
```
ui.button((Image::new("image.png"), "Click me!"))
```
to get a button with image and text.
This PR reimplements three egui widgets based on the new AtomLayout:
- Button
- matches the old button pixel-by-pixel
- Button with image is now [properly
aligned](https://github.com/emilk/egui/pull/5830/files#diff-962ce2c68ab50724b01c6b64c683c4067edd9b79fcdcb39a6071021e33ebe772)
in justified layouts
- selected button style now matches SelecatbleLabel look
- For some reason the DragValue text seems shifted by a pixel almost
everywhere, but I think it's more centered now, yay?
- Checkbox
- basically pixel-perfect but apparently the check mesh is very slightly
different so I had to update the snapshot
- somehow needs a bit more space in some snapshot tests?
- RadioButton
- pixel-perfect
- somehow needs a bit more space in some snapshot tests?
I plan on updating TextEdit based on AtomLayout in a separate PR (so
you could use it to add a icon within the textedit frame).
This is the same change as in #4069 but as this is stale I wanted to
reopen a non stale PR
Modifies ImageLoader's load function to use background threads for the
image decoding work. This avoids blocking the main thread that is
especially noticeable when loading many images at once.
This was modelled after the other loader implementations that also use
threads.
* Closes <https://github.com/emilk/egui/issues/5375>
* [x] I have followed the instructions in the PR template
---------
Co-authored-by: lucasmerlin <lucasmeurer96@gmail.com>
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
The bug was in `Color32::from_rgba_unmultiplied` and by extension
affects:
* `Color32::from_rgba_unmultiplied`
* `hex_color!`
* `HexColor`
* `ColorImage::from_rgba_unmultiplied`
* All images with transparency (png, webp, …)
* `Color32::from_white_alpha`
The bug caused translucent colors to appear too bright.
## More
Color is hard.
When I started out egui I thought "linear space is objectively better,
for everything!" and then I've been slowly walking that back for various
reasons:
* sRGB textures not available everywhere
* gamma-space is more _perceptually_ even, so it makes sense to use for
anti-aliasing
* other applications do everything in gamma space, so that's what people
expect (this PR)
Similarly, pre-multiplied alpha _makes sense_ for blending colors. It
also enables additive colors, which is nice. But it does complicate
things. Especially when mixed with sRGB/gamma (As @karhu [points
out](https://github.com/emilk/egui/pull/5824#issuecomment-2738099254)).
## Related
* Closes https://github.com/emilk/egui/issues/5751
* Closes https://github.com/emilk/egui/issues/5771 ? (probably; hard to
tell without a repro)
* But not https://github.com/emilk/egui/issues/5810
## TODO
* [x] I broke the RGBA u8 color picker. Fix it
---------
Co-authored-by: Andreas Reich <andreas@rerun.io>
This adds a generic way of telling containers to close from their child
`Ui`s.
* Part of #5727
* [x] I have followed the instructions in the PR template
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
I got annoyed by all the slightly different variations of "collect
snapshot results and unwrap them at the end of test" I've written, so I
added a struct to make this nice and simple.
One controversial thing: It panics when dropped. I wanted to ensure
people cannot forget to unwrap the results at the end, and this was the
best thing I could come up with. I don't think this is possible via
clippy lint or something like that.
* [x] I have followed the instructions in the PR template
Breaking change!
* `Rounding` -> `CornerRadius`
* `rounding` -> `corner_radius`
This is to:
* Clarify
* Conform to other systems (e.g. Figma)
* Avoid confusion with `GuiRounding`
## Defining what `Rounding` is
This PR defines what `Rounding` means: it is the corner radius of
underlying `RectShape` rectangle. If you use `StrokeKind::Inside`, this
means the rounding is of the outer part of the stroke. Conversely, if
you use `StrokeKind::Outside`, the stroke is outside the rounded
rectangle, so the stroke has an inner radius or `rounding`, and an outer
radius that is larger by `stroke.width`.
This definitions is the same as Figma uses.
## Improving general shape rendering
The rendering of filled shapes (rectangles, circles, paths, bezier) has
been rewritten. Instead of first painting the fill with the stroke on
top, we now paint them as one single mesh with shared vertices at the
border. This has several benefits:
* Less work (faster and with fewer vertices produced)
* No overdraw (nicer rendering of translucent shapes)
* Correct blending of stroke and fill
The logic for rendering thin strokes has also been improved, so that the
width of a stroke of `StrokeKind::Outside` never affects the filled area
(this used to be wrong for thin strokes).
## Improving of rectangle rendering
Rectangles also has specific improvements in how thin rectangles are
painted.
The handling of "Blur width" is also a lot better, and now works for
rectangles with strokes.
There also used to be bugs with specific combinations of corner radius
and stroke width, that are now fixed.
## But why?
With the new `egui::Scene` we end up with a lot of zoomed out shapes,
with sub-pixel strokes. These need to look good! One thing led to
another, and then I became obsessive 😅
## Tessellation Test
In order to investigate the rendering, I created a Tessellation Test in
the `egui_demo_lib`.
[Try it
here](https://egui-pr-preview.github.io/pr/5669-emilkimprove-tessellator)
This is a breaking change, requiring users to think about wether the
stroke is inside/centered/outside the rect.
When in doubt, add `egui::StrokeKind::Inside` to the function call.
Previously, `Harness::run` just called `Harness::step` 3 times. If that
wasn't enough, tests would often call run multiple times so all
animations would finish properly.
Also, I introduced `HarnessBuilder::with_step_dt` to customize with how
big of a dt each frame is called. I set the default to 1.0 / 6.0 (~6fps)
so we don't waste cpu in tests waiting on animations.
`HarnessBuilder::max_steps` allows us to control how many steps
`Harness::run` should run before panicing.
The default is 6, so we run for up to 1.0 logical seconds (six frames at
6 fps), which should be enough to finish most animations.
Turns out a lot of snapshots where rendered before fully shown and had a
light opacity, those are now fixed.
* [x] I have followed the instructions in the PR template
* Part of https://github.com/emilk/egui/issues/4019
`Frame` now includes the width of the stroke as part of its size. From
the new docs:
### `Frame` docs
The total (outer) size of a frame is `content_size + inner_margin +
2*stroke.width + outer_margin`.
Everything within the stroke is filled with the fill color (if any).
```text
+-----------------^-------------------------------------- -+
| | outer_margin |
| +------------v----^------------------------------+ |
| | | stroke width | |
| | +------------v---^---------------------+ | |
| | | | inner_margin | | |
| | | +-----------v----------------+ | | |
| | | | ^ | | | |
| | | | | | | | |
| | | |<------ content_size ------>| | | |
| | | | | | | | |
| | | | v | | | |
| | | +------- content_rect -------+ | | |
| | | | | |
| | +-------------fill_rect ---------------+ | |
| | | |
| +----------------- widget_rect ------------------+ |
| |
+---------------------- outer_rect ------------------------+
```
The four rectangles, from inside to outside, are:
* `content_rect`: the rectangle that is made available to the inner
[`Ui`] or widget.
* `fill_rect`: the rectangle that is filled with the fill color (inside
the stroke, if any).
* `widget_rect`: is the interactive part of the widget (what sense
clicks etc).
* `outer_rect`: what is allocated in the outer [`Ui`], and is what is
returned by [`Response::rect`].
### Notes
This required rewriting a lot of the layout code for `egui::Window`,
which was a massive pain. But now the window margin and stroke width is
properly accounted for everywhere.
This adds `WidgetType::Image` and correctly sets it in the Image widget.
This allows us to query for images in kittest tests and tells accesskit
that a node is an image.
It also adds `Image::alt_text` to set a text that will be shown if the
image fails to load and will be read via screen readers. This also
allows us to query images by label in kittest.
* [x] I have followed the instructions in the PR template
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Hey! I am not sure if this is something that's been considered before
and decided against (I couldn't find any PR's or issues).
This change removes the internal profiling macros in library crates and
the `puffin` feature and replaces it with similar functions in the
[profiling](https://github.com/aclysma/profiling) crate. This crate
provides a layer of abstraction over various profiler instrumentation
crates and allows library users to pick their favorite (supported)
profiler.
An additional benefit for puffin users is that dependencies of egui are
included in the instrumentation output too (mainly wgpu which uses the
profiling crate), so more details might be available when profiling.
A breaking change is that instead of using the `puffin` feature on egui,
users that want to profile the crate with puffin instead have to enable
the `profile-with-puffin` feature on the profiling crate. Similarly they
could instead choose to use `profile-with-tracy` etc.
I tried to add a 'tracy' feature to egui_demo_app in order to showcase ,
however the /scripts/check.sh currently breaks on mutually exclusive
features (which this introduces), so I decided against including it for
the initial PR. I'm happy to iterate more on this if there is interest
in taking this PR though.
Screenshot showing the additional info for wgpu now available when using
puffin
<!--
Please read the "Making a PR" section of
[`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md)
before opening a Pull Request!
* Keep your PR:s small and focused.
* The PR title is what ends up in the changelog, so make it descriptive!
* If applicable, add a screenshot or gif.
* If it is a non-trivial addition, consider adding a demo for it to
`egui_demo_lib`, or a new example.
* Do NOT open PR:s from your `master` branch, as that makes it hard for
maintainers to test and add commits to your PR.
* Remember to run `cargo fmt` and `cargo clippy`.
* Open the PR as a draft until you have self-reviewed it and run
`./scripts/check.sh`.
* When you have addressed a PR comment, mark it as resolved.
Please be patient! I will review your PR, but my time is limited!
-->
* [X] I have followed the instructions in the PR template
Emil Ernerfeldt
Lucas Meurer
Ian Hobson
Kumpelinus
valadaptive
Lucas Meurer
Nicolas
TÖRÖK Attila
Ted de Munnik
Tristan Guichaoua