Add AtomLayout, abstracing layouting within widgets#5830
Conversation
|
Preview available at https://egui-pr-preview.github.io/pr/5830-lucasexperimentswidgetlayout |
This is mostly in preparation for #5830 where I want to ensure that I don't introduce any regressions
9b01154 to
d468565
Compare
AtomicLayout that abstracts layouting within widgetsAtomicLayout, abstracing layouting within widgets
emilk
left a comment
There was a problem hiding this comment.
Please run some benchmarks (the ones that are already there, and maybe some new ones more focused on e.g. just Button)
|
|
||
| harness | ||
| .get_by_label("Submenu C (CloseOnClickOutside)") | ||
| .get_by_label_contains("Submenu C (CloseOnClickOutside)") |
There was a problem hiding this comment.
Does the label not contain more than just the text?
There was a problem hiding this comment.
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.
|
Remember to run |
…h the current one. - offset frame margin for stroke width - handle expansion - add min_size - calculate image size based on font height - correctly handle alignment / ui layout
# Conflicts: # crates/egui/src/widgets/button.rs
AtomicLayout, abstracing layouting within widgetsAtomLayout, abstracing layouting within widgets
### Related - atomics landed in egui (emilk/egui#5830) ### What Updates egui to latest master and uses atoms in the help view, removing the icon_text macro since it was basically atomics lite Seems like the snapshots the only thing that changed is the three dot icon slightly moved. But it seems a bit clearer now, so that's a win.
This is mostly in preparation for emilk#5830 where I want to ensure that I don't introduce any regressions
This helped me benchmark the atomic layout (emilk#5830) changes. I also realized that the label benchmark wasn't testing the painting, since the buttons at some point will be placed outside the screen_rect, meaning it won't be painted. This fixes it by benching the label in a child ui. The `label &str` benchmark went from 483 ns to 535 ns with these changes. EDIT: I fixed another benchmark problem, since the benchmark would show the same widget millions of times for a single frame, the WidgetRects hashmap would get huge, causing each iteration to slow down a bit more and causing the benchmark to have unreliable results. With this the `label &str` benchmark went from 535ns to 298ns. Also the `label format!` benchmark now takes almost the same time (302 ns). Before, it was a lot slower since it reused the same Context which already had millions of widget ids.
* In preparation of emilk#5830, this should reduce the performance impact of that PR --------- Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
Today each widget does its own custom layout, which has some drawbacks:
ImagetoButtonbut it will always be shown on the left sideImageto a e.g. aSelectableLabelThis PR introduces
AtomsandAtomLayoutwhich 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:
The initial implementation only does very basic layout, just enough to be able to implement most current egui widgets, so:
There is a trait
IntoAtomsthat conveniently allows you to constructAtomsfrom a tupleto get a button with image and text.
This PR reimplements three egui widgets based on the new AtomicLayout:
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).