You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The link is a bit of a terrible abstraction to handle background threads via egui. The way it works is that when an action should be performed in the background, it will send the action over a crossbeam channel to a separate thread which continuously listens for input from the channel. The thread processes the action (e.g. performs a query) and sends it back.
Egui, in the default event loop, will check for any response in the receiver crossbeam channel (e.g. 30 times per second on 30fps). If a response is available it will be applied.
There're a couple of downsides to this:
Request and Response are separated which makes it very difficult to use the Engine via Link in a non-async context.
WASM doesn't support threads, so there is a wonky abstraction to allow sync access (with way too many cfg(target_arch = wasm32)
This solution requires multiple additional abstractions which make it all a bit confusing to understand.
Egui apparently would work from separate threads but this might not work for other UI libraries (if we ever port it). So maybe a solution would be to have a SyncLink and AsyncLink with a closure that makes sure the request matches the response.
The text was updated successfully, but these errors were encountered:
The link is a bit of a terrible abstraction to handle background threads via egui. The way it works is that when an action should be performed in the background, it will send the action over a crossbeam channel to a separate thread which continuously listens for input from the channel. The thread processes the action (e.g. performs a query) and sends it back.
Egui, in the default event loop, will check for any response in the receiver crossbeam channel (e.g. 30 times per second on 30fps). If a response is available it will be applied.
There're a couple of downsides to this:
cfg(target_arch = wasm32
)Egui apparently would work from separate threads but this might not work for other UI libraries (if we ever port it). So maybe a solution would be to have a SyncLink and AsyncLink with a closure that makes sure the request matches the response.
The text was updated successfully, but these errors were encountered: