Add AtomLayout, abstracing layouting within widgets

[lucasmerlin]

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:

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 AtomicLayout:

• Button
  • matches the old button pixel-by-pixel
  • Button with image is now properly aligned 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 AtomicLayout in a separate PR (so you could use it to add a icon within the textedit frame).

[github-actions]

Preview available at https://egui-pr-preview.github.io/pr/5830-lucasexperimentswidgetlayout
Note that it might take a couple seconds for the update to show up after the preview_build workflow has completed.

[emilk]

Please run some benchmarks (the ones that are already there, and maybe some new ones more focused on e.g. just Button)

[emilk]

Does the label not contain more than just the text?

[lucasmerlin]

I added a todo for this here:
https://github.com/emilk/egui/pull/5830/files#diff-7fd879073a3ce1839ef5c8fdd4dc5e50afc139c018b71c35ca5660bf89420470R657-R673

The text now unfortunately contains the ⏵ from the submenu button. Not sure what a good solution is to handle this. Maybe a flag on the Atomic? Maybe the Atomic could have a alt_text you could use for images, and if you add a text like ⏵ you could do "⏵".a_alt_text("") or something like that.
This would also solve accessibility for Icon Fonts.

[emilk]

Remember to run cargo doc -p egui --open and check the docs for the new top-level types. Some are missing, some are bad

[lucasmerlin]

Ran the demo benchmark for main and the PR and it seems to be slightly slower but I feel the slow down is acceptable for the features we gain:

	Demo Realistic	Demo No Tesselate	Demo Only Tesselate
Master	109.83 µs	73.938 µs	38.209 µs
Atomics	112.93 µs	75.127 µs	38.099 µs

See this comment for the button benchmark results.

[emilk]

nit: sort

[lucasmerlin]

mnopqrstu... It should be sorted correctly

[emilk]

Unrelated to this PR: I suspect this grid would be a lot easier to read if we replaced all cross_/main_ with horiz_/vert_ instead, e.g. so that the rightmost column is always horiz_align: Right

[emilk]

AtomicLayout is 432 bytes now. Most of that is Atomics (360 bytes), because it has a SmallVec 2x of Atomic (176 bytes), most of which is Image (152 bytes).

Not something we need to fix right now; I just wanted to investigate it a bit.

A quick fix would be to change AtomicKind::Image into a Box<Image>, i.e. optimize for the case where there is no image. That shrinks AtomicLayout from 432 to to 176 bytes, a 60% reduction.