AssetManager–Texture cache key: do loader parameters participate in cache identity?

Question

ContextlibGDX's AssetManager caches loaded assets by a key derived from the file name and, for some loaders, the loader parameters. TextureLoader does not consistently include TextureParameter fields (such as minFilter, magFilter, genMipMaps) in that key. Consequently, a texture loaded once with Nearest filtering and no mipmaps may be returned again when a later request specifies Linear filtering with mipmaps, because the cache treats both requests as identical.GoalDetermine whether the current cache-key contract guarantees parameter-sensitive isolation for Texture assets, or whether callers must manually unload and reload to obtain a texture with different GPU state.Constraints and uncertaintyDocumentation states that AssetManager returns the same instance for identical keys, but does not enumerate which loader parameters are folded into the key for each loader.Texture.setFilter() mutates the shared GPU object, affecting all holders of that instance.No built-in reload(String, Parameter) API exists to force parameter-aware replacement.Behavior may differ between libGDX 1.12.x and newer snapshots.QuestionsIs the omission of TextureParameter from the cache key intentional design or an oversight?What is the recommended pattern for obtaining a texture with different filter/mipmap settings without leaking the previous GPU resource?Does any loader (e.g., BitmapFontLoader) demonstrate the parameter-inclusive key strategy that TextureLoader could adopt?

Tasadduq Burney · Answer

AnswerNo – libGDX’s TextureLoader does not fold TextureParameter fields (e.g., minFilter, magFilter, genMipMaps) into the AssetManager cache key. The key is based solely on the file name, so two load calls for the same image with different parameters return the exact same Texture instance.Confirmed factsThe cache key for TextureLoader is derived only from the asset file name; parameter objects are ignored.Other loaders that accept parameters (e.g., BitmapFontLoader) do include their parameter objects in the key, showing that the omission is not a deliberate design choice.Because the same Texture instance is shared, calling setFilter() on it changes the GPU state for every holder, which can cause unintended rendering artifacts.Recommended stepsIf you need a texture with different filter or mipmap settings, either dispose the existing texture and reload it, or load the texture under a distinct synthetic name (e.g., myimage.png#linear) to force a new cache entry.After disposing, ensure no other code retains a reference to the old texture to avoid GL errors.

AssetManager–Texture cache key: do loader parameters participate in cache identity?

Context

Goal

Constraints and uncertainty

Questions

1 answer

Answer

Confirmed facts

Recommended steps

Your perspective belongs here.

0 question comments