Closed hervegirod closed 11 years ago
Ah, that's a good point. I thought I had a reason for that structure of the code earlier, but I had never implemented expunging stale entries.
The old version seems to work well (apart from the necessity to explicitly destroy stale Textures).
Fixed in cc1e8038c074e69379f8830602c4e95456ad78dc to use the ReferenceQueue to destroy unused textures.
Hello,
It seems that there is a problem in the Texture cache (imageCache field) of the AbstractImageHelper class. It is a WeakHashMap, but when elements are removed from the Map (for example when you clear the Map), the native textures are not destroyed in the JOGL world, and you might have a memory leak.
We used the previous version with a ReferenceQueue (when you removed stale entries), but still the destroy(GL) method was never called, and when we changed the content of the image we had a continuous increase of native memory used (not Java memory of course), and finally a crash. When we took care of destroying the native memory each time a WeakEntry has become stale, then the crashes disappeared. I think that even if the structure of the code has changed, you might still have the same problem now.
Hervé