Add a method for asynchronously waiting for an asset to load #14431
Conversation
joseph-gio
added
A-Assets
alice-i-cecile
added
the
C-Usability
|
This method already exists called Does not return a future but is arguably more flexible. |
alice-i-cecile
added
the
S-Needs-Review
|
And of course, the main advantage of |
The reason |
| /// | ||
| /// This will return an error if the asset or any of its dependencies fail to load, | ||
| /// or if the asset has not been queued up to be loaded. | ||
| pub async fn wait_for_asset_id( |
There was a problem hiding this comment.
I think it would be more ergonomic to return a 'static future, maybe based on event_listener::Event?
Can be simplified to event.listen().await
There was a problem hiding this comment.
I originally used a 'static future for wait_for_asset_id, but I changed it to non-static for consistency with the wait_for_asset{_untyped}, and to avoid unnecessarily cloning the AssestServer when _id() is used to implement the other methods. I'm neutral on if we keep it this way or not
| @@ -37,6 +38,8 @@ pub(crate) struct AssetInfo { | |||
| /// The number of handle drops to skip for this asset. | |||
| /// See usage (and comments) in `get_or_create_path_handle` for context. | |||
| handle_drops_to_skip: usize, | |||
| /// List of tasks waiting for this asset to complete loading | |||
| pub(crate) waiting_tasks: Vec<Waker>, | |||
There was a problem hiding this comment.
Maybe more ergonomic to use event_listener::Event?
|
@JoJoJet, I'd like to get this into 0.15. Can you resolve merge conflicts? |
bushrat011899
added
S-Waiting-on-Author
alice-i-cecile
added
S-Adopt-Me
|
Closing as adopted. |
#15913) # Objective Currently, is is very painful to wait for an asset to load from the context of an `async` task. While bevy's `AssetServer` is asynchronous at its core, the public API is mainly focused on being used from synchronous contexts such as bevy systems. Currently, the best way of waiting for an asset handle to finish loading is to have a system that runs every frame, and either listens for `AssetEvents` or manually polls the asset server. While this is an acceptable interface for bevy systems, it is extremely awkward to do this in a way that integrates well with the `async` task system. At my work we had to create our own (inefficient) abstraction that encapsulated the boilerplate of checking an asset's load status and waking up a task when it's done. ## Solution Add the method `AssetServer::wait_for_asset`, which returns a future that suspends until the asset associated with a given `Handle` either finishes loading or fails to load. ## Testing - CI ## Notes This is an adoption of #14431, the above description is directly from that original PR. --------- Co-authored-by: Joseph <21144246+JoJoJet@users.noreply.github.com> Co-authored-by: andriyDev <andriydzikh@gmail.com>
Objective
Currently, is is very painful to wait for an asset to load from the context of an
asynctask. While bevy'sAssetServeris asynchronous at its core, the public API is mainly focused on being used from synchronous contexts such as bevy systems. Currently, the best way of waiting for an asset handle to finish loading is to have a system that runs every frame, and either listens forAssetEvents or manually polls the asset server. While this is an acceptable interface for bevy systems, it is extremely awkward to do this in a way that integrates well with the async task system. At my work we had to create our own (inefficient) abstraction that encapsulated the boilerplate of checking an asset's load status and waking up a task when it's done.Solution
Add the method
AssetServer::wait_for_asset, which returns a future that suspends until the asset associated with a givenHandleeither finishes loading or fails to load.Testing
TODO