I’ve seen some leaking occur before related to fonts and multithreading. Also static fonts can cause some issues if I remember correctly. Where is variable f coming from? maybe try your example without setting the font, and then without any of the text drawing at all, does it make a difference?
What instrument are you using to detect these “leaks”?
We often get false alarms when people see the task manager’s memory use value for the process seem to rise, and don’t understand that it’s a very poor indicator of what’s really going on in the app.
Xcode’s instruments include awesome tools for memory debugging, and if you use them properly it’ll show you exactly what’s leaking (or more likely not leaking, since we’re pretty sure that nothing in the basic juce graphics system has a leak).
That sounds reasonable. I’m using the basic performance monitor tab in the left frame. It matches the system activity monitor. I’ll know to use more advanced tools next time.
If a process’ memory usage continues to rise without limit as long as it is running, it is almost certainly leaking.
Sometimes memory usage appears to grow for a few hours and then peaks, but if it continues to grow indefinitely without bounds there is almost certainly a leak. Xcode’s tools are good, but they are not foolproof and they can be turned off. If the leak occurs indirectly because of the way a library that JUCE wraps is being used (rather than directly as a result of allocation in JUCE itself) then Xcode’s tools will never detect it.
I refer you to this discussion from 2013: ComponentAnimator memory leak
In this discussion you initially made all these same points, then did some investigation and wrote:
“Ok… doing some digging, it seems that there’s an issue where the Images that ComponentAnimator uses are being deleted while the GL context is no longer active, which means their textures can’t be freed, and they get leaked. I’ll get on the case and sort this out…”