This provides a better estimate of a typical frametime in reactive mode.
From the docstring of `stable_dt`:
Time since last frame (in seconds), but gracefully handles the first frame after sleeping in reactive mode.
In reactive mode (available in e.g. `eframe`), `egui` only updates when there is new input or something animating.
This can lead to large gaps of time (sleep), leading to large [`Self::unstable_dt`].
If `egui` requested a repaint the previous frame, then `egui` will use
`stable_dt = unstable_dt;`, but if `egui` did not not request a repaint last frame,
then `egui` will assume `unstable_dt` is too large, and will use
`stable_dt = predicted_dt;`.
This means that for the first frame after a sleep,
`stable_dt` will be a prediction of the delta-time until the next frame,
and in all other situations this will be an accurate measurement of time passed
since the previous frame.
Note that a frame can still stall for various reasons, so `stable_dt` can
still be unusually large in some situations.
When animating something, it is recommended that you use something like
`stable_dt.min(0.1)` - this will give you smooth animations when the framerate is good
(even in reactive mode), but will avoid large jumps when framerate is bad,
and will effectively slow down the animation when FPS drops below 10.
When painting a scatter plot we sometimes want to paint hundreds of thousands of points (filled circles) on screen every frame.
In this PR the font texture atlas is pre-populated with some filled circled of various radii. These are then used when painting (small) filled circled, which means A LOT less triangles and vertices are generated for them.
In a new benchmark we can see a 10x speedup in circle tessellation, but the the real benefit comes in the painting of these circles: since we generate a lot less vertices, the backend painter has less to do.
In a real-life scenario with a lot of things being painted (including around 100k points) I saw tessellation go from 35ms -> 7ms and painting go from 45ms -> 1ms. This means the total frame time went from 80ms to 8ms, or a 10x speedup.
* Remove integration name (it is always eframe)
* Remove egui_web crate
* Move egui_web/CHANGELOG.md into eframe/CHANGELOG.md
* Remove all mentions of egui_web
* Remove epi crate and absorb into eframe
* egui_glow: only use puffin on native
* Remove WASM doc from CI (we don't generate it anyways!)
* Remove eframe::epi and improve eframe docs
* Returns openness in CollapsingResponse
* Make CollapsingState a building block for custom collapsing headers
* Add a demo of the custom collapsing header
* Revert to much simpler tree demo
* Add CollapsingState::is_open and CollapsingState::set_open
This looks like a Hyperlink, but doesn't do anything when clicked.
Or rather: it lets the user decide what happens on click.
Closes https://github.com/emilk/egui/issues/1152
* Move examples out of eframe/examples into examples/
Give each example a `Cargo.toml` and `src/main.rs`.
This makes it easier for people to use as templates.
* Update README.md with more deps needed on vanilla Ubuntu
* Install libgtk-3-dev on CI, hoping that will fix something
* Update to rust 1.60.0
* Rename the feature `convert_bytemuck` to `bytemuck`
* Rename the feature `serialize` to `serde`.
* Make use of the "weak dependency" cargo feature
* Set rust-version = "1.60" for all crates
* egui_glow: clipboard, links, persistence & winit are now opt-in features
Id clashes can cause subtle bugs.
egui already warns when the same Id is used to interact with different
parts of the screen.
This adds warnings about id clashes for some widgets that store state:
Grid, Plot, ScrollArea, Table.
The PR also adds `Context::check_for_id_clash` so users who create
their own widgets can add the same type of check.
* Rename AlphaImage to FontImage to discourage any other use for it
* Encode FontImage as f32 and postpone the alpha correction
* Interpret alpha coverage in a new, making dark text darker, improving contrast in bright mode
* Fix code that could lead to a possible deadlock.
Drop implementations are not called until the end of a statement. The statement changed in this commit therefore took 4 read locks on a RwLock which can lead to problems if a write lock is requested between any of these read locks. The code looks like it would only hold one lock at a time but it does not drop any of the locks until after the arithmatic operations complete, which leads to this situation. See https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=996079046184329f3a9df1cd19c87da8 to see this in action. The fix is to just take one lock and share it between the three calls to num_presses, letting it drop at the end of the scope.
* Fix code that may cause a deadlock in `MenuRoot::stationary_interaction`
The issue here is related to that in 9673b8f2a08302c10ffcfd063f2dbdec4301d3e2 in that the lock is not dropped when it is expected. Since the `RwLockReadGuard` produced by `ctx.input()` has a reference taken from it (one into `pointer`), the lock cannot be dropped until that reference is no longre valid, which is the end of the scope (in this case this function). The following `ctx.input()` then attempts to aquire a second lock on the `RwLock`, creating the same situation that was found in the referenced commit.
This has been resolved by holding one lock on the input for the whole function.
* Reference this PR from comments in the code for future maintainers
* Add the change to the changelog
* Use full link to PR
* Use full link to PR
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
This adds a callback (set by `Context::set_request_repaint_callback`)
which integration can use to wake up the UI thread.
eframe (egui_web and egui_glow) will use this, replacing
`epi::Frame::request_repaint`.
Existing code calling `epi::Frame::request_repaint` should be changed
to instead call `egui::Context::request_repaint`.
This is the first callback added to the egui API, which otherwise is
completely driven by data.
The purpose of this is to remove the confusion between the two
`request_repaint` methods (by removing one). Furthermore, it makes
`epi::Frame` a lot simpler, allowing future simplifications to it
(perhaps no longer having it be `Send+Sync+Clone`).
* Add Shape::Callback to do custom rendering inside of an egui UI
* Use Rc<glow::Context> everywhere
* Remove trait WebPainter
* Add glow::Context to epi::App::setup
