-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider making egui::Context !Send+!Sync #1399
Comments
https://github.com/asny/three-d recently merged a PR adding `glow` support: asny/three-d#210 This means it is a prime candidate for embedding 3D painting inside an eframe app. There are currently a few kinks that need to be figured out: When reusing the same three_d context over time (as one should), we only get one frame of egui together with three_d, and then after that a black screen with just the three_d painting on top. I need to fix that before merging this PR. `Shape` is `Send + Sync` and `three_d::Context` is not. This means we cannot store a three_d context and send it to the `Shape::Callback`. So we either need to recreate the three_d context each frame (obviously a bad idea), or access it through a `thread_local` hack. This PR adds both as examples, with a checkbox to switch. We could consider making `Shape: !Send + !Sync`, but that would mean `egui::Context` could not be `Send+Sync` either (because the egui context stores shapes). This is discussed in #1399
https://github.com/asny/three-d recently merged a PR adding `glow` support: asny/three-d#210 This means it is a prime candidate for embedding 3D painting inside an eframe app. There are currently a few kinks that need to be figured out: When reusing the same three_d context over time (as one should), we only get one frame of egui together with three_d, and then after that a black screen with just the three_d painting on top. I need to fix that before merging this PR. `Shape` is `Send + Sync` and `three_d::Context` is not. This means we cannot store a three_d context and send it to the `Shape::Callback`. So we either need to recreate the three_d context each frame (obviously a bad idea), or access it through a `thread_local` hack. This PR adds both as examples, with a checkbox to switch. We could consider making `Shape: !Send + !Sync`, but that would mean `egui::Context` could not be `Send+Sync` either (because the egui context stores shapes). This is discussed in #1399
I'm looking into this, removing locks entirely from the |
@Pjottos thank you so much for working on this! |
I got the demo to compile and run without a lock on the context. Seems to be working as expected |
With wgpu marking its types At the moment, if you want to access any wgpu types in your custom callbacks you can't store them directly in a struct impl'ing By making Context |
In wgpu 0.17 wgpu types are not Send + Sync, because they reference things in the JS heap (meaning they cannot leave the thread they were created on) egui_wgpu's CallbackTrait requires Send + Sync even on wasm and we need to store wgpu types in callbacks. The callback_resources typemap passed to callbacks doesn't need to be Send + Sync.. but I can't find a simple way to add anything to the typemap. emilk/egui#1399 feels relevant
* refactor: 🚧 Split luminol into separate crates * refactor: 🚧 Start working out dependencies * Sorta figure out dependencies * Sorta start getting somewhere * Move Luminol into crates folder * Move the filesystem trait out of luminol-core * refactor: 🚧 refactor luminol-graphics and it's a mess * refactor: * refactor: add UpdateState to luminol-core and move various traits * refactor(filesystem): ♻️ require FileSystem::File to be 'static * refactor: ♻️ don't take an &'static reference to graphics state * refactor: ♻️ refactor modals * refactor: ♻️ unify tabs and windows * refactor: ♻️ start to fix up windows * refactor: ♻️ hack together things so that they compile * refactor: ♻️ partially resolve async code issues * refactor: ♻️ it compiles (with a LOT of unfinished things) * refactor: ♻️ NOW it compiles * fix(graphics): 🐛 fix sprite shader compilation * fix(data cache): ♻️ get data cache semi-working * refactor(data cache): ♻️ actually load data cache * refactor(config): ♻️ store code theme in global state again * fix(ui): 🐛 fix windows and tabs not being added * refactor: ♻️ use workspace metadata for package metadata * refactor: ♻️ remove generic parameters on update state by using dynamic dispatch I couldn't get generics to allow adding tabs or windows inside tabs or windows * refactor(tabs): ♻️ pass update state when requesting tab name * fix(tabs): 🐛 fix tabs not adding properly * Update window.rs * fix: 🐛 get top bar loading projects * fix: 🐛 fix new project creation because reqwest requires tokio we need to spawn a tokio runtime. i do not think this scales well to web * refactor: 🚧 try splitting up the map tab * Enable -Zthreads compiler flag * Update nightly in workflows * revert: ⏪ Undo making cursor state an enum (will tackle this later) * Sorta resolve dependencies on wasm Still a mess (and is especially complicated by the fact that you can't specify workspace target specific dependencies) * Fix backing web filesystem implementation Still need to work on the project filesystem though! I'll be honest, I'm not sure how this will work, especially with the way I have the native filesystem set up * Fix native build * Remove jobs flag * Fix audio on wasm * Temporarily impl Send + Sync for wgpu callbacks In wgpu 0.17 wgpu types are not Send + Sync, because they reference things in the JS heap (meaning they cannot leave the thread they were created on) egui_wgpu's CallbackTrait requires Send + Sync even on wasm and we need to store wgpu types in callbacks. The callback_resources typemap passed to callbacks doesn't need to be Send + Sync.. but I can't find a simple way to add anything to the typemap. emilk/egui#1399 feels relevant * Fix winit not compiling in CI emilk/egui#3228 * Get wasm filesystem compiling * Get luminol compiling on wasm! * Fix missed rename * Dumb typo * Move luminol crate to be root package Trunk doesn't like virtual workspaces unfortunately :( * Run workspace tests * fix(audio): 🐛 Completely read audio file on wasm * perf(wasm): ⚡ Use oneshot crate for oneshot channels * fix(filesystem): 🐛 Pass idb key instead of path to Filesystem::from_idb_key * refactor(tilemap): ♻️ Use naga oil instead of const_format * fix(ui): 🐛 Fix top bar opening & closing projects * Bump nightly in trunk build * Remove luminol- in folder prefixes
Prompted by #1398
Currently
Context
andShape
are bothSend+Sync
. This meansShape::Callback
can only capture things that areSend+Sync
, even though almost all users will be running their UI code on the the paint thread.We could consider making
Shape: !Send + !Sync
, but that would meanegui::Context
could not beSend+Sync
either (because the egui context stores shapes). This could actually be fine.egui::Context
should only be used from a background thread for callingrequest_repaint
and allocating textures. These could be made separate parts of the egui Context, so that one would do:Making
Context: !Sync
would also solve deadlocks discussed in #1379 and #1380.The downside of this is that it would stop users from running their UI code in a separate thread from their main window/paint thread.
Related:
The text was updated successfully, but these errors were encountered: