OF 0.11.1 Out soon - please help test

general discussion
#1

Hi all,

0.11.1 Patch Release will be out soon.

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 )

If you want to help test please try out the nightly builds at the bottom of the downloads page:
https://openframeworks.cc/download/

If you run into any issues please report them here:

Or in this thread.

Thanks!!

7 Likes
#2

Hi,

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:

18
18904×1037 173 KB

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…

Edit: Same for intel build.

Edit2: Same bahaviour with graphics example:

23
231185×649 89.8 KB

Cheers
Teo

#3

Hmm. That is strange.
Thanks for the report!

With your draw code

For 0.11.0 on an Intel MBP I get:

image

For 0.11.1 / nightly after letting it run for 30 mins I get:

image

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.

On intel I get:

image
image1024×685 277 KB

#4

Hi,

I’ve checked leaks:

55
551279×827 201 KB

No leaks detected but allocated memory is still growing…

Cheers, Teo

#5

Hey Teo,

I can reproduce this on my M1 Mac Mini. It seems to be tied to glDrawArrays or any other gl draw function.

I think for a while now Apple Emulates OpenGL via Metal so there could be a bug with the translation / emulation on arm64 machines.

Or it could be on OF’s end too, maybe something with the glew library?

Going to dig into this more and also update my system to the latest OS.

Edit: does seem like something with Apple Metal GL Renderer ( see highlighted line )

image
image1200×803 339 KB

Thanks for reporting this!
Theo

#6

So this def seems to be an OF bug.

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.

Annoying it is glfw master too. :frowning:

Getting closer though! :slight_smile:

2 Likes
#7

On the latest macOS Big Sur (11.2.1), ofSetupOpenGL(1024,768, OF_WINDOW); makes a window of 512 x 384. Is this a new feature or a bug?

#8

@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?

Thanks
Teo

#9

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.

Thanks!
Theo

1 Like
#10

Ah that is definitely not a new feature :slight_smile:
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.

image
image1450×648 127 KB

Thanks!

1 Like
#11

Yes, that works for me for either x86 or arm64 build :slight_smile: Thanks for the workaround!

1 Like
#12

I’ll try this on my build. that was the issue I was mentioning here

#13

Hello Theo, the GLFW only makes no difference but the plist does the trick. Thanks

1 Like
#14

Thanks @dimitre!
Apologies - I didn’t realize it was happening by default on retina in Big Sur. :slight_smile:

Thanks for checking the plist fix.
That will be easy to do.

1 Like
#15

I confirm what @dimitre said. Replacing glfw folder did not work, but adding High Resolution Capable in the plist did work. Thanks Theo!

2 Likes
#16

@TeoDumski @dimitre @jaeho
I think the current nightly builds should have both the retina fixes and weird arm64 mem leak fixes.

If you have a moment could you give them a try and see if it all seems to be fixed?

Thanks!
Theo

1 Like
#17

retina fixed here! thank you!

1 Like
#18

@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