PixiJS Asset Proposal #7639
Replies: 2 comments 3 replies
-
I am not sure I understand how and where the In other notes, |
Beta Was this translation helpful? Give feedback.
-
I dont care about
If you have API for that, its sold to me! |
Beta Was this translation helpful? Give feedback.
-
PixiJS Asset Proposal
By Mat Groves, Matt Karl
Overview
The goal of this document is to identify the current challenges related to loading and caching assets in PixiJS and propose a solution to streamline and modernize how we resolve, load and cache resources.
Problems
No Single-Source of Truth
Resource Loader maintains a per-instance cache and PixiJS maintains its own static caches ( TextureCache, BaseTextureCache). Having multiple points of caching means that assets can get loaded twice or easily blocked from garbage collection. This creates a lot of confusion for complicated applications that load and unload resources.
Duplicate Loading Mechanism
BaseTexture resources have implemented their own way to load resources. Whether that be loading SVGs or images as HTMLImageElements. There are redundant loading strategies between Loader and Resources that creates a maintenance headache. Generally, Resource Loader is well tested and the internal loading mechanism in BaseTexture resources is not well tested.
Legacy Callback API Design
Loader uses an API design that’s largely inherited or inspired from ActionScript3. Loader instances are created and callbacks are used for handing the result or errors. This OOP style has largely been replaced with Promise with APIs like fetch. It makes it easier to read code using async/await.
Poor Separation of Concerns
Having multiple caches fighting with each other means that there is poor separation of concerns between network management, URL resolving, asset parsing, and asset management. We need an API that more accurately manages these problems. Also, many core objects like Sprite, Texture and BaseTexture know TOO much about the cache. Convenience methods like Texture.from or storing cache keys on the objects creates complexity.
Lack of Multithreading
Network traffic throttles performance. Being able to use Workers and multithreading would improve performance overall for loading and parsing assets.
Limit Resolving for Assets
There are normal situations where you may want to request a different asset, that could be a newer less ubiquitous format like WebP over PNG, or different resolution (e.g. @2x) or if you’re using compressed-textures. Regardless, most of this responsibility is put on the developer to figure out what they need to resolve.
Poor Caching for New Objects
The caching system isn’t flexible enough to support caching of other objects, both high-level like Mesh or low-level like Program. These instances require their own side-car caching schemas or ref-counting. There’s not a generic way to add to the global cache.
Introducing Assets
We’d like to introduce a new @pixi/assets package that would be a dependency of @pixi/core. This package would create three new systems to address the issues above: loader, resolver and cache.
Asset Loader
This is a new loading API that would replace the existing Loader. Here are some of the features:
Example
Proposed
Current (v6)
Asset Resolver
Resolve an asset with various inputs into a single network request. Inspired by the compressed texture manifest to resolve various texture formats. Features include:
Example
Asset Cache
The magic glue class that will join the above systems together. Assets will be our one stop shop for any asset type. Long-term replacing external cache based functions such as Texture.from. In the short term, Assets can run underneath the .from calls.
Example
Further Questions
Lazy Loading
PixiJS currently supports a style of lazy-loading Textures. You can use, implement and add to your display a Texture that is invalid and hasn’t finished loading. Should Textures continue to support lazy-loading?
The case for continuing to keep lazy-loading:
The case for removing lazy-loading:
BaseTextureCache
Does PixiJS continue to need a BaseTextureCache? This could just be a function on the normal TextureCache - as All base textures can be retrieved by retrieving the texture with the url from the cache and accessing its base Texture.
New API
This proposed solution is what we have been using internally on Goodboy projects for the last year (bypassing the current Resource Loader). It is battle-tested and works really well, and I’m keen to bring these benefits to the rest of the PixiJS community.
Beta Was this translation helpful? Give feedback.
All reactions