If you want to see the changes since 0.11.0 check out the changelog here:
Since 0.11.0 there is 64bit msys2 builds, working emscripten again and macOS builds should be compatible with Big Sur and Apple M1 Silicon. ( need to add some of this to the changelog )
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):
void ofApp::draw(){
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:
Memory consumption is constantly growing while program is running. Is it normal behaviour? Do we need to free framebuffer somehow after drawing 500 lines? Or am I missing something?
Unfortunately, there is no valgrind tool available for arm64 arch, so I cannot test for memory leaks…
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.
I tried the 0.11.0 release I patched to work on arm here and there is no memory leak.
I also tried a bunch of OpenGL and GLFW examples and they also don’t have this issue.
So will take a look and see what that changed between 0.11.0 and 0.11.1 / patch-release.
Edit: Looks like it is something with GLFW. If I replace the glfw in the 0.11.0 link above with the one from the nightly ( or even GLFW master ) I see the memory increase.
@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.
Ah that is definitely not a new feature
I think someone else mentioned this and I assumed they had enabled retina by default. But I think that might be a new GLFW / Big Sur thing that is happening.
Could you try replacing the glfw folder in libs/ with the one from this zip and see if it fixes the issue?
I don’t have a retina machine on Big Sur to reproduce this unfortunately.
If that doesn’t work. Can you try adding this line to your openFrameworks-Info.plist in your Xcode project.
@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
Thank you
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