BaseTextureCache vs TextureCache

[autumn8]

I'm struggling to understand why textures are selectively added to BaseTextureCache and/or TextureCache. I'd be grateful if someone could shed some light on this.

 

Eg. in v3.0.7 

 

- loading an asset with assetloader results in texture being added to textureCache,

- whereas loading the asset using convenience methods (fromImage etc) ends up with texture being added to both BaseTextureCache & TextureCache.

- fromCanvas only seems to create texture in BaseTextureCache.

 

Thanks,

b

 

 

[xerver]

THe loader not putting something into BaseTexture cache was an oversight, I should fix that.

 

That being said TextureCache and BaseTextureCache are internal mechanisms that you probably shouldn't be interacting with. Usually you only need to use the loader and the resulting resources object that contains all your loaded assets. I suggest you pretend those caches don't exist.

[autumn8]

Thanks for the response.

 

I'm not looking to fiddle with the cache's but we have tight memory usage requirements, so I'm really just stepping through the library to try and understand in an effort to ensure that I'm destroying things efficiently. Another thing I noticed is:

 

1) Calling destroy(true, true) on assets loaded through convenience methods like fromImage removes the asset from both TextureCache and BaseTextureCache because the texture has an imageURL. This is what I would expect to happen, but

 

2) calling destroy(true, true) on a texture that was  loaded with assetLoader doesn't remove them from either TextureCache or BaseTextureCache as they don't have an imageURL or source._pixiId. The texture is also not removed from loader resources.  Is all of this expected behaviour? 

[xerver]

> calling destroy(true, true) on a texture that was loaded with assetLoader doesn't remove them from either TextureCache or BaseTextureCache as they don't have an imageURL or source._pixiId. The texture is also not removed from loader resources. Is all of this expected behaviour?

Good catch, that is a bug. I would report it on the GitHub tracker. As for the resources object of the loader you can make it drop its references to loaded resources by calling .reset()