-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Context::request_repaint will wake up the UI thread (#1366)
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`).
- Loading branch information
Showing
12 changed files
with
46 additions
and
48 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -359,13 +359,6 @@ impl Frame { | |
self.lock().output.drag_window = true; | ||
} | ||
|
||
/// This signals the [`egui`] integration that a repaint is required. | ||
/// | ||
/// Call this e.g. when a background process finishes in an async context and/or background thread. | ||
pub fn request_repaint(&self) { | ||
self.lock().repaint_signal.request_repaint(); | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
quietvoid
Contributor
|
||
} | ||
|
||
/// for integrations only: call once per frame | ||
pub fn take_app_output(&self) -> crate::backend::AppOutput { | ||
std::mem::take(&mut self.lock().output) | ||
|
@@ -524,24 +517,13 @@ pub const APP_KEY: &str = "app"; | |
pub mod backend { | ||
use super::*; | ||
|
||
/// How to signal the [`egui`] integration that a repaint is required. | ||
pub trait RepaintSignal: Send + Sync { | ||
/// This signals the [`egui`] integration that a repaint is required. | ||
/// | ||
/// Call this e.g. when a background process finishes in an async context and/or background thread. | ||
fn request_repaint(&self); | ||
} | ||
|
||
/// The data required by [`Frame`] each frame. | ||
pub struct FrameData { | ||
/// Information about the integration. | ||
pub info: IntegrationInfo, | ||
|
||
/// Where the app can issue commands back to the integration. | ||
pub output: AppOutput, | ||
|
||
/// If you need to request a repaint from another thread, clone this and send it to that other thread. | ||
pub repaint_signal: std::sync::Arc<dyn RepaintSignal>, | ||
} | ||
|
||
/// Action that can be taken by the user app. | ||
|
This change causes problems with calling
ctx.request_repaint
on another thread that did not exist when calling onframe
.Frame
always uses astd::sync::Mutex
to lock its state which makes this code fine to call from another thread as it will just block if the mutex is locked.Context
on the other hand switches between using anAtomicRefCell
and aparking_lot::Mutex
depending on ifepaint/multi_threaded
is enabled (which it normally is not when using eframe. So whenctx.request_repaint
is called from another thread and the ui thread has a lock on theContext
the application just panics with the following message:The solution to this would be to just have a way to enable or enable by default the
multi_threaded
feature on epaint. But it would leave this discrepency between different parts of code usingstd::sync::Mutex
,parking_lot::Mutex
andAtomicRefCell
for depending on features or just what part of the code they are in. Standardizing all of them to useparking_lot
's synchronization would be my suggestion, but again theCargo.toml
forepaint
does note a minor performance impact when not usingAtomicRefCell
in a single threaded context:egui/epaint/Cargo.toml
Lines 52 to 54 in c8f6cae