Jump to content

Patterns for loaders and texture cache


Recommended Posts

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:


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:


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) {
} else {
  let loader = new PIXI.Loader();

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 by jasonsturges
Link to comment
Share on other sites

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

Link to comment
Share on other sites

@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 by jasonsturges
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...