I’ve noticed that by calling Addressables.LoadAsset there is ALWAYS at least one frame delay before the loadTask completes even if the asset is stored locally, further more the Task seems to be updated by the main thread so there is no parallelism going on there and there!
I get that the call is meant to be asynchronous but shouldn’t the returned Task at least be updated on a parallel thread so we programmers can choose to wait for that Task to finish if we want to provide synchronous loads?
At the very least I shouldn’t be forced to loose a frame every time I want to load an asset…
Is there any plan to fix this?
As to operating on another thread, we’ve looked into it, but it’s not doable for many of the engine systems we’re building on top of. We intend to look into it more to investigate.
Thank you unity_bill! Hope you guys find a way to resolve the 1 frame delay… If I read correctly the Synch trick doesn’t currently work for all modes and all platform so I’m not going to be using it in the end… but good to know it is somehow possible.
You can wrap the system in your own asset manager, hold the references to already loaded objects, then when you request that asset, return Task.FromResult(obj). I do exactly that in my project (though I use promises instead of Tasks, but that’s a moot point).
As of Addressable 1.19, there is AsyncOperationHandle.WaitForCompletion() that force the load request to complete in the same frame like Resouces.Load. Example:
var request = Addressables.LoadAssetAsync<Sprite>(path);
request.WaitForCompletion());