Patterns for loaders and texture cache

[jasonsturges]

My pixi app consumes a lot of texture resources:

• Default icons / images built-in to the app
• Project specific assets dynamically loaded at runtime through serialization of json documents
• Realtime updates via multiple datasources from APIs and Phoenix channel sockets

Seems ideal to just pummel a shared loader, but there are issues.

If I try to add resources while a shared loader is already running, I get the error:

Quote

Cannot add resources while the loader is running

So instead, I always create a loader instance, but I have to avoid adding the same asset twice or I receive the warning:

Quote

Texture added to the cache with an id [example-asset.png] that already had an entry

I can check the global texture cache first, and then call a handler, which becomes a bit obtuse:

if (imageUrl in PIXI.utils.TextureCache) {
  imageLoadedHandler();
} else {
  let loader = new PIXI.Loader();
  loader.add(imageUrl);
  loader.load();
  loader.onComplete.add(imageLoadedHandler);
}

But if the asset is still loading, it's not yet in the texture cache.

Example: There are bulk user changes where a default user avatar is applied to multiple users.  When that occurs, the first 4 or so start to load, but aren't in the texture cache yet.  Once load is complete, the logic above works but I still end up with warnings from the first concurrent asynchronous loads.

Crux here:

• Wish there was a queue loader with completion handlers per asset, or some way to simplify callbacks to manage textures with less boilerplate
• Or, some way to check instance pending queue in a global way - these local Loader instances can't reflect pending loads in their own queue across instances... unless I'm mistaken here...
• Some kind of `async await` pattern with `PIXI.Sprite.from()` or something would be dreamy

Mostly this is single asset handling, like a User Sprite that features its own built-in loader to apply an avatar png image.

This probably makes little sense, and likely is edge case to the larger community as I'd imagine most apps don't manage this magnitude of assets in such a dynamic way.

 

 

Edited August 24, 2021 by jasonsturges

[ivan.popelyshev]

yeah, loader per one resource is usual thing after adding resources in runtime became restricted. You can add resource only if it has parentResource, I dont remember why this invariant was added.

How to do for such projects with dynamic textures? I used my own loader for that, and even my own texture Resource's with placeholders when texture isnt ready yet

[jasonsturges]

@ivan.popelyshev That makes sense - I had a feeling it was time to write a custom loader, just wanted to make sure I wasn't missing something.

Cool, sounds like a fun project.  In the unlikely instance I come up with anything revolutionary, I'll share back with the community.

Thanks, as always!

Edited August 24, 2021 by jasonsturges
Typo