Previously a single-negative rectangle (where `min.x > max.x` XOR `min.y
> max.y`) would return a negative area, while a doubly-negative
rectangle (`min.x > max.x` AND `min.y > max.y`) would return a positive
area. Now both return zero instead.
## What
(written by @emilk)
When editing long text (thousands of line), egui would previously
re-layout the entire text on each edit. This could be slow.
With this PR, we instead split the text into paragraphs (split on `\n`)
and then cache each such paragraph. When editing text then, only the
changed paragraph needs to be laid out again.
Still, there is overhead from splitting the text, hashing each
paragraph, and then joining the results, so the runtime complexity is
still O(N).
In our benchmark, editing a 2000 line string goes from ~8ms to ~300 ms,
a speedup of ~25x.
In the future, we could also consider laying out each paragraph in
parallel, to speed up the initial layout of the text.
## Details
This is an ~~almost complete~~ implementation of the approach described
by emilk [in this
comment](<https://github.com/emilk/egui/issues/3086#issuecomment-1724205777>),
excluding CoW semantics for `LayoutJob` (but including them for `Row`).
It supersedes the previous unsuccessful attempt here:
https://github.com/emilk/egui/pull/4000.
Draft because:
- [X] ~~Currently individual rows will have `ends_with_newline` always
set to false.
This breaks selection with Ctrl+A (and probably many other things)~~
- [X] ~~The whole block for doing the splitting and merging should
probably become a function (I'll do that later).~~
- [X] ~~I haven't run the check script, the tests, and haven't made sure
all of the examples build (although I assume they probably don't rely on
Galley internals).~~
- [x] ~~Layout is sometimes incorrect (missing empty lines, wrapping
sometimes makes text overlap).~~
- A lot of text-related code had to be changed so this needs to be
properly tested to ensure no layout issues were introduced, especially
relating to the now row-relative coordinate system of `Row`s. Also this
requires that we're fine making these very breaking changes.
It does significantly improve the performance of rendering large blocks
of text (if they have many newlines), this is the test program I used to
test it (adapted from <https://github.com/emilk/egui/issues/3086>):
<details>
<summary>code</summary>
```rust
use eframe::egui::{self, CentralPanel, TextEdit};
use std::fmt::Write;
fn main() -> Result<(), eframe::Error> {
let options = eframe::NativeOptions {
..Default::default()
};
eframe::run_native(
"editor big file test",
options,
Box::new(|_cc| Ok(Box::<MyApp>::new(MyApp::new()))),
)
}
struct MyApp {
text: String,
}
impl MyApp {
fn new() -> Self {
let mut string = String::new();
for line_bytes in (0..50000).map(|_| (0u8..50)) {
for byte in line_bytes {
write!(string, " {byte:02x}").unwrap();
}
write!(string, "\n").unwrap();
}
println!("total bytes: {}", string.len());
MyApp { text: string }
}
}
impl eframe::App for MyApp {
fn update(&mut self, ctx: &egui::Context, _frame: &mut eframe::Frame) {
CentralPanel::default().show(ctx, |ui| {
let start = std::time::Instant::now();
egui::ScrollArea::vertical().show(ui, |ui| {
let code_editor = TextEdit::multiline(&mut self.text)
.code_editor()
.desired_width(f32::INFINITY)
.desired_rows(40);
let response = code_editor.show(ui).response;
if response.changed() {
println!("total bytes now: {}", self.text.len());
}
});
let end = std::time::Instant::now();
let time_to_update = end - start;
if time_to_update.as_secs_f32() > 0.5 {
println!("Long update took {:.3}s", time_to_update.as_secs_f32())
}
});
}
}
```
</details>
I think the way to proceed would be to make a new type, something like
`PositionedRow`, that would wrap an `Arc<Row>` but have a separate `pos`
~~and `ends_with_newline`~~ (that would mean `Row` only holds a `size`
instead of a `rect`). This type would of course have getters that would
allow you to easily get a `Rect` from it and probably a `Deref` to the
underlying `Row`.
~~I haven't done this yet because I wanted to get some opinions whether
this would be an acceptable API first.~~ This is now implemented, but of
course I'm still open to discussion about this approach and whether it's
what we want to do.
Breaking changes (currently):
- The `Galley::rows` field has a different type.
- There is now a `PlacedRow` wrapper for `Row`.
- `Row` now uses a coordinate system relative to itself instead of the
`Galley`.
* Closes <https://github.com/emilk/egui/issues/3086>
* [X] I have followed the instructions in the PR template
---------
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
<!--
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!
-->
Title. This would have helped me debug bugs quicker.
* [x] I have followed the instructions in the PR template
<!--
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!
-->
Title.
* [x] I have followed the instructions in the PR template
<!--
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!
-->
- I fixed the TODO to use the `log` crate instead of `eprintln`
- Set the rust-version in the `scripts/check.sh` to the same as egui is
on
- I made xtask use anyhow to remove some unwraps
* [x] I have followed the instructions in the PR template
<!--
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!
-->
I removed (I hope so) all wildcard imports I found.
For me on my pc this improved the build time:
- for egui -5s
- for eframe -12s
* [x] I have followed the instructions in the PR template
<!--
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 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!
-->
I find myself wanting this API quite a lot, and I imagine it'll probably
be useful for others.
# What?
This PR adds `Rect::scale` and `Rect::scale2` functions, which work a
lot like `expand`, but instead multiply by a scale.
i.e.
```rs
rect.scale(2.0); // rect is 2x as big, still in same center
rect.scale2(vec2(1.5, 2.0)); // rect is 1.5x as big on x axis, 2.0x as big on y axis. still in same center
```
# Why?
Before this you either had to write this yourself or use a `expand` in a
cumbersome way:
```rs
rect.expand2(vec2(rect.width() * scale.x / 2.0, rect.height() * scale.y / 2.0));
```
I find myself wanting to scale things up by a factor frequently enough,
and it seems like a useful addition to have a multiply-based variant of
`expand`.
I realise this is pretty minor, but it seems useful enough to me!
---------
Co-authored-by: zkldi <20380519+zkldi@users.noreply.github.com>
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
# What
Adds `#[doc(alias = "top_left")]` as an alias for `left_top`, and so on
for `right_top`, `right_bottom`, `left_bottom`.
# Why
Extremely minor doc-only change, but I keep going to type "top left" to
look for the top left of a rectangle.
I'm unsure whether this is just a british-english thing or an
english-in-general thing, but `top left corner` is far more common than
`left top corner`.
These doc aliases don't conflict with anything, and mean that
rust-analyzer will suggest the correct function when I search for the
wrong thing.
This improves ergonomics and discoverability in my opinion, even if not
by much.
This fixes a bug which sometimes would make it possible to interact with
widgets that were outside the parent clip_rect.
Interaction with a widget is done with the `interact_rect`, which is the
intersection of the widget rect and the parent clip rect. If these
rectangles are disjoint (the widget is outside the parent clip rect),
this results in a _negative rectangle_ (a rectangle with a negative
width and/or height). The distance tests for negative rectangles were
broken, causing the bug.
* This is part of solving https://github.com/emilk/egui/issues/4475
* It is also likely this would have solved
https://github.com/emilk/egui/issues/4349 (which now has another fix for
it)
### Breaking changes
`Rect::distance_to_pos`, `distance_sq_to_pos`, `signed_distance_to_pos`
now all return `f32::INFINITY` if the rectangle is negative.
These three types currently have a `Debug` implementation that only ever
prints one decimal point. Sometimes it is useful to see more of the
number, or otherwise have specific formatting.
Add `Display` implementations that pass the format specification to the
member `f32`s for an easier way to control what is shown when debugging.
This allows doing e.g. `ui.label(format!("{:.4}", rect * scale))` which
currently prints zeroes if scale is small.
* Part of https://github.com/emilk/egui/issues/3556
## In short
You now almost never need to use `eframe::Frame` - instead use
`ui.input(|i| i.viewport())` for information about the current viewport
(native window), and use `ctx.send_viewport_cmd` to modify it.
## In detail
This PR removes most commands from `eframe::Frame`, and replaces them
with `ViewportCommand`.
So `frame.close()` becomes
`ctx.send_viewport_cmd(ViewportCommand::Close)`, etc.
`frame.info().window_info` is now also gone, replaced with `ui.input(|i|
i.viewport())`.
`frame.info().native_pixels_per_point` is replaced with `ui.input(|i|
i.raw.native_pixels_per_point)`.
`RawInput` now contains one `ViewportInfo` for each viewport.
Screenshots are taken with
`ctx.send_viewport_cmd(ViewportCommand::Screenshots)` and are returned
in `egui::Event` which you can check with:
``` ust
ui.input(|i| {
for event in &i.raw.events {
if let egui::Event::Screenshot { viewport_id, image } = event {
// handle it here
}
}
});
```
### Motivation
You no longer need to pass around the `&eframe::Frame` everywhere.
This also opens the door for other integrations to use the same API of
`ViewportCommand`s.
* Move scroll bar spacing settings to a `struct ScrollSpacing`
* Add a demo for changing scroll bar appearance
* Add setting for ScrollBarVisibility in demo
* Add `#[inline]` to a `ScrollArea` builder methods
* Refactor how scroll bar show/hide is computed
* Add support for floating scroll bars
* Tweak color and opacity of the scroll handle
* Allow allocating a fixed size even for floating scroll bars
* Add three pre-sets of scroll bars: solid, thin, floating
* Use floating scroll bars as the default
* Fix id-clash with bidir scroll areas
* Improve demo
* Fix doclink
* Remove reset button from demo
* Fix doclinks
* Fix visual artifact with thin rounded rectangles
* Fix doclink
* typos
* Give credit to recent big-time contributors in the main README.md
* Better named profiling scopes
* Document everything in memory.rs
* Better doc-strings
* Add a section about dependencies to the main README.md
* Improve egui_extras docs
* fix typos
* Fix the "ever-growing height" problem of Strip and Table Demos
Problem
-------
The height of "Table Demo" or "Strip Demo" floating window grows
when the demo app is interacted with. If 'Continuous' mode is enabled
in 'Backend' settings, the window grows irrespectively of user interaction.
Observations
------------
I noticed that [`area_content_ui.min_rect().max.y`][1] is increasing
monotonically with speed 0.5 px/frame.
I also noticed that commenting out `ui.add(crate::egui_github_link_file!());`
[statement][2] in `table_demo.rs` makes the problem disappear.
The "Fix"
---------
I added 0.5 to the height of the row with GitHub link.
This solved the problem.
Closes#3029.
Warning
-------
I failed to find the root cause of the problem.
I don't understand why this change makes the problem disappear.
[1]: 9478e50d01/crates/egui/src/containers/window.rs (L403)
[2]: 9478e50d01/crates/egui_demo_lib/src/demo/table_demo.rs (L114)
* Document `Rect::size`
Other changes:
- `area.rs`: Use existing API.
- `table_demo.rs`: Remove unnecessary call.
