* egui-winit: don't assume window available at init
On Android in particular we can only initialize render state once we
have a native window, after a 'Resumed' lifecycle event. It's still
practical to be able to initialize an egui_winit::State early on
so this adds setters for the max_texture_side and pixels_per_point
that can be called once we have a valid Window and have initialized
a graphics context.
On Wayland, where we need to access the Display for clipboard handling
we now get the Display from the event loop instead of a window.
* egui-wgpu: lazily initialize render + surface state
Enable the renderer and surface state initialization to be deferred
until we know that any winit window we created has a valid native window
and enable the surface state to be updated in case the native window
changes.
In particular these changes help with running on Android where winit
windows will only have a valid native window associated with them
between Resumed and Paused lifecycle events, and so surface creation
(and render state initialization) needs to wait until the first
Resumed event, and the surface needs to be dropped/recreated based on
Paused/Resumed events.
arboard advertises that it works with Wayland, but in reality it only
works with Wayland terminal applications. To make the clipboard work
with applications that draw Wayland surfaces, arboard isn't going to
work.
Copypasta does support Wayland's graphical clipboard, but the usage
isn't documented. However, for the reasons mentioned in #1474 the move
from Copypasta to arboard makes sense.
To resolve the issue, this commit brings in an optional dependency
smithay-clipboard, that is a crate that correctly handles the Wayland
clipboard in graphical applications. It is used by default if a Wayland
window handle is found. If for some reason the handle to the Wayland
window handle cannot be fetched, arboard is used as a backup.
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.
Based on https://github.com/hasenbanck/egui_wgpu_backend
`egui-wgpu` is now an official backend for `eframe` (opt-in).
Use the `wgpu` feature flag on `eframe` and the `NativeOptions::renderer` settings to pick it.
Co-authored-by: Nils Hasenbanck <nils@hasenbanck.de>
Co-authored-by: Sven Niederberger <niederberger@embotech.com>
Co-authored-by: Sven Niederberger <73159570+s-nie@users.noreply.github.com>
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.
`egui_demo_app/lib`: add "About egui" window, and improve mobile layout
This makes the app responsive, removing the side bars on mobile and turning them into drop-down menus instead.
* Make the strip demo less ugly
* revert duplicated windows dependency in Cargo.lock
* cargo update
* Remove duplicated windows dependency by reverting rfd
* And again for parking_lot_core
Emil Ernerfeldt
sy1ntexx
Robert Bragg
Sebastian Urban
Florian Diebold
Zicklag
griffi-gh
Erlend Walstad
Antti Keränen
Stanislav
Luke Newcomb
TicClick
4JX
Nigecat
Alejandro Perea
carrotflakes
Reilly Moore
René Rössler