Make better use of cache in loaders

[dubejf]

ImageLoader and XHRLoader both use a Cache to store loaded assets for reuse, although not very efficiently, at least for some use case.

For instance, TextureLoader.onload() creates a new ImageLoader every time the method is called, which means that the image cache is always empty because the image loader instance is only used once. ImageUtils.loadTexture() behaves similarly.

My preferred way to solve this would be to put the cache in the LoadingManager (one cache per LoadingManager instance). Each ImageLoader and XHRLoader would share the cache of their parent manager.

Users would be responsible to manually purge the manager cache as necessary, to free resources or request updated assets. That could be a problem for an application that cycles through a lot of loaded textures/images, especially if the DefaultLoadingManager is used - users might not be aware of cache implication. Maybe the common cache could be opted-in (loadingManager.useCache = true), which would be equivalent to the status quo. A simple loadingManager.cache.maxSize could be enough, too.

Another approach would be to create an ImageLoader instance as a property of TextureLoader in its constructor. The image cache would be reused as long as the same TextureLoader is kept around.

I can work on a patch if we agree on the approach.

Related to #3601

[mrdoob]

Maybe Cache could be global?

[dubejf]

The initial implementation of the Cache was global but was changed the next day (a072f1f) to the current implementation. @mrdoob, do you remember what was the issue? Problem multiple renderers?

I've experimented a bit with the cache/loader, although I'm not completely sure about the approach.

To get the 'global' behavior, I've simply added the cache to the LoadingManager.

However, that is not sufficient to solve #3601. The problem here is uncoordinated concurrent retrieval of the same resource, and it needs more that a cache. My solution to get around this problem is to introduce a CacheLoader.

You can see it in action here: http://jsfiddle.net/dubejf/r9n8b0b4/4/

Basically, instead of ImageLoader answering each 'load' request directly, the modified ImageLoader puts the loaded images in the CacheLoader, and the CacheLoader answers the original 'load' callbacks. CacheLoader understands when a request is 'in progress', and can combine multiple requests for the same resource.

CacheLoader is asynchronous. It should be possible to patch it to use a WeakMap or IndexedDB if desired. The approach is also general enough that I might start to use it to de-duplicate identical instances other types of object, e.g. Geometry and Materials.

However, it adds a some complexity, and I'm not sure how big of a problem the lack of caching is in general.

[mrdoob]

Hmmm... Stupid me... I should detail more why I do changes... I don't remember why I made it not global...

CacheLoader seems interesting. I'll study all this 😊

[bnolan]

This would help my use case. In the chess game, the pawns are loaded 8 times, when the cached version of the .obj could be saved and reused. :)

[mrdoob]

scenevr is interesting! I like the spheres to open portals idea 😀

We can add caching to more loaders, but it also sound like for your case you could handle that on your side too...

[antont]

@dubejf - about what you say, "I'm not sure how big of a problem the lack of caching is in general."

In my understand it is a big problem. We've dealt with it in own code, outside three.js, but it might be nice to have it work properly in three already if there's a simple nice clear way.

[bnolan]

I ended up solving this by creating an AssetManager. I could make this into an npm module if there was any interest. I also parse the .objs using a webworker, but I might look into .gltf to see if it's even faster.