Questions About Asset Loading on Browser

[zicklag]

I have a couple questions about how asset loading works for Bevy in the browser:

1. When I asset_server.load() an asset multiple times, it makes multiple network requests and downloads that asset multiple times. Should the asset server be caching the Handle<MyAsset> so that if I assset_server.load() the same path it will just give me a clone of the already-created handle? I thought this is what Bevy did, but I don't know where I got that idea so I may have made it up. 😅
2. When my web game downloads an asset it freezes the game during the download. Shouldn't the download be async and let the game run while it is downloading the asset?

[mockersf]

1. It will give you the same handle, but will still try to load the file in case it changed
2. We don't really have multithread in wasm... there are discussions about how to improve that with web workers I think, but nothing in Bevy yet. you can check Web Support #88 (comment) for the latest one I'm aware of

[zicklag]

Awesome, thanks!

1. Good to know. For my own app I figure I'll make an asset_server.load_with_cache() using an extension trait on AssetServer, but I wonder if that's something useful to be included in Bevy.
2. OK. Maybe I'll try my hand at some sort of multi-threading on WASM then. No promises I'll get anything worth anything, though. 😉

[zicklag]

Looking at the Bevy Task implementation it actually looks like the asset loading shouldn't block at all. It's not multi-threaded, but it should be async and non-blocking:

bevy/crates/bevy_tasks/src/single_threaded_task_pool.rs

Lines 86 to 96 in ed36c21

	// Spawns a static future onto the JS event loop. For now it is returning FakeTask
	// instance with no-op detach method. Returning real Task is possible here, but tricky:
	// future is running on JS event loop, Task is running on async_executor::LocalExecutor
	// so some proxy future is needed. Moreover currently we don't have long-living
	// LocalExecutor here (above `spawn` implementation creates temporary one)
	// But for typical use cases it seems that current implementation should be sufficient:
	// caller can spawn long-running future writing results to some channel / event queue
	// and simply call detach on returned Task (like AssetServer does) - spawned future
	// can write results to some channel / event queue.
	pub fn spawn<T>(&self, future: impl Future<Output = T> + 'static) -> FakeTask

I'll have to do more investigation as to waht might be blocking in my case.

[zicklag]

Ah, it's my asset loader that is freezing it. It's the actual OGG parser that is stalling the frame:

As far as I understand I think that means that the OGG loader, because it isn't async and doesn't have any await calls in it, it is never yielding to the async executor and will therefore freeze the whole WASM thread until it finishes.

That would mean that the only way to fix it would be to somehow add yield points to the OGG parser or to figure out how use web workers to create a worker pool.