I’m not sure if it’s related only to new release but I noticed a strange behaviour. I was playing with some neural network visualisation and realized that my app uses more and more memory. When I stripped all non-relevant code I relized that it’s happening even with trivial project drawing 500 lines in draw function (only):
for (int i=0; i < 500; i++)
ofDrawLine (100, i*3, 800, i*4);
When using Xcode build for arm64 (Apple Silicon) memory consumption looks like that:
For 0.11.1 / nightly after letting it run for 30 mins I get:
So I don’t think it is a general leak relating to the OF code.
It could be something in one of the libs we use, but I am guessing it might be more to do with the way macOS handles memory on M1 devices.
One thing you could try is using the Xcode profiler with Product -> Profile and then run the leaks checker profiler.
@theo, Glad to hear you’ve getting closer. I assume this can be kind of important cause it potentially decreases stability of many OF apps. Could you drop a line about how to replace GLFW in nightly release with that older one?
If you replace the glfw folder in the nightly download ( in the libs/ folder ) with the one from this zip, it should fix the issue.
I have narrowed it down to something that happened between GLFW 3.2.1 and 3.3. But unfortunately 3.3 is a huge release with a lot of rewriting of most of the mac specific classes.
I can’t seem to reproduce it though with GLFWs own examples so it could be something we are missing that is now required in 3.3. Either way I think going back to 3.2.1 for 0.11.1 would be good. Then we can try and update for 3.3 for 0.12.0.
@Theo I’ve just noticed the retina issue plist fixes for Xcode build but not for make (vscode) one.
Is there a way of making it work with make? I think there is a plist file being written on config.osx.default.mk
EDIT: In fact I’ve tested here and it works.
I’ve added camera and microphone plist entries too and created a pull request here