Mac Mojave + opengl

Question

Mac OS 10.14 Mojave was just released, and since June, we've known that OpenGL was to be deprecated in the OS. "OpenGL applications will continue to run, but you should switch to Metal," to paraphrase. However, there doesn't seem to be any documentation indicating whether you can still compile with OpenGL or if Apple prevents that or omits the proper development libraries. I am currently developing an OpenGL-based graphics program and cannot risk updating if compilation will no longer work. Has anyone tested this?

EDIT: Does anyone else share Esenthel's experience?

My application builds, runs and renders fine with OpenGL on 10.14 / Xcode 10. — TheNextman, Sep 26 '18 at 17:03
@TheNextman Do you have any thoughts on why the others are having issues? — synchronizer, Sep 26 '18 at 17:48
I suspect a programming error that didn't manifest in earlier versions :) It's hard to say without more details. I would note that I see the warning in my console that's mentioned in @Esenthel link. I see it on startup and believe it's totally benign (or at least, a red herring). Best advice I can give is backup, upgrade, try it out. If it doesn't work, you can rollback to your backup while you figure it out. — TheNextman, Sep 26 '18 at 20:36
I'm getting a black screen like Esenthel and like @Marcus Åkerman I am using SDL2 and if I drag the window, the rendering appears and everything is fine after that. I'll look into the SDL fix he mentions. — msc, Oct 02 '18 at 23:55
Same here. The workaround posted by Chris (reshape) fixed my problems. — Tomasz Slanina, Oct 07 '18 at 05:55
The workaround does not work for me. glGetError returns a GL_FRAMEBUFFER_UNDEFINED, the screen stays black. — digory doo, Oct 20 '18 at 19:47

Esenthel · Answer 1 · 2019-01-10T10:04:40.050

7

I can compile, however after updating to latest Mojave and Xcode, my OpenGL applications simply don't work.

In one case I get a hang during a system GL call, in another case just a black screen. And some errors in the output same as here: https://stackoverflow.com/questions/52507950/unable-to-load-info-plist-error-xcode-10-under-macos-10-14-mojave#=

I recommend that you don't update.

I think there's something broken in Xcode 10 OpenGL libraries.

Edit: It appears that later Mac OS and Xcode updates have fixed the problems.

edited Jan 10 '19 at 10:04

answered Sep 26 '18 at 09:31

Esenthel

499
4
17

Ouch, that's actually very bad. I expected things to keep working for a while at least. – synchronizer Sep 26 '18 at 15:55
I still need to set-up tools on high sierra (the hardware shipped with that OS). Can I still get XCode 9 on there? – synchronizer Sep 26 '18 at 16:08
It looks like I can switch between 9 and 10 at will. I'm not sure if I should just stick with 9 though. – synchronizer Sep 26 '18 at 17:50
Is the "later Mac OS and Xcode updates have fixed the problems" remark still valid after the Mojave 10.14.3 update from about Jan. 23? I'm getting no rendering if I use Xcode 10.1. If I build with Xcode 9.4.1, all is well. – JWWalker Jan 24 '19 at 22:36
I confirm that after updating to Mojave 10.14.3 and Xcode 10.1 this issue has been fixed. No need to do the little hack for making this code run. – Raydelto Hernandez Mar 09 '19 at 11:49

score 5 · Answer 2 · answered Dec 14 '18 at 00:51

GLFW work around. Similar to other answers, but you do not need to resize your window in the draw loop, just call glfwPollEvents() first.

window = glfwCreateWindow(width-1, height, "Hello World", NULL, NULL);
glfwPollEvents();
glfwSetWindowSize(window, width, height);

Also, glfwHideWindow() then glfwShowWindow() seems to work. Similarly glfwSetWindowPos() is an alternative. Though setting the window size seems faster than hide/showing the window, and I don't want to move the window position.

score 2 · Answer 3 · answered Oct 05 '18 at 14:01

The code at

http://people.bath.ac.uk/abscjkw/ComputerPrograms/C++programs/OpenGL/MojaveOpenGL.cpp

works fine in Mojave with Xcode 10.0. The window is resized automatically to get rid of the black. OpenGL and GLUT frameworks are added to the project from the usual place, /System/Library/Frameworks

Chris

score 1 · Answer 4 · edited Sep 28 '18 at 18:55

1

I'm using GLEW, GLUT, OpenGL 2.0 and SDL 2. I can compile and run my OpenGL application. However I had to change my Framework Search Paths to include:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks

where OpenGL and GLUT framework + headers are now placed as I couldn't find any OpenGL/GLUT headers in the old search path System/Library/Frameworks (although the framework was still there, no headers were included). I also had to make sure my includes were GLUT/glut.h instead of just glut.h.

This gives me new warning messages in form of:

[default] Unable to load Info.plist exceptions (eGPUOverrides)" and "saved enable noise cancellation setting is the same as the default (=1)

I haven't checked them yet, and what their implications are.

What really bugs me is what Esenthel says, that there is just a black screen after compiling and running the app. I found that if you drag the app window (I'm not using full screen) then the animation starts to show. Apparently the animation is in the background and all code is evaluating, but there is only a black screen until I drag the window.

EDIT: I'm using Mojave and Xcode 10 (not beta).

edited Sep 28 '18 at 18:55

zzxyz

2,953
1
16
31

answered Sep 28 '18 at 16:53

Marcus Åkerman

21
5

If you have a new question, please ask it by clicking the [Ask Question](https://stackoverflow.com/questions/ask) button. Include a link to this question if it helps provide context. - [From Review](/review/low-quality-posts/20990294) – mustaccio Sep 28 '18 at 17:16
mustaccio: There is no question from me following from my answer. I don't understand your input. I answered synchronizer's question, stating my experience when upgrading my application from 9+ and High Sierra to 10+ with Mojave. – Marcus Åkerman Sep 28 '18 at 17:52
@MarcusÅkerman Perhaps that's a spam bot. Anyway, it looks like Apple isn't including the proper headers. The black window bug was on SDL's end. It's been fixed in the bleeding edge branch but you'd have to compile it yourself for now. I'm not going to be using Xcode by the way, and I'm using SDL2, GLEW, and OpenGL 4.1 – synchronizer Sep 29 '18 at 00:45
1

@synchronizer, I pulled the bleeding edge of libSDL master and rebuilt my libSDL but it is not helping. I see changeset #12261, which looks a likely fix, But I still have a black window until I drag it. I stopped at a breakpoint in the new code to ensure I'm hitting it. I am. On resuming after that break, and disabling the breakpoint, the window draws normally. The problem occurs whether running from Xcode or running the app directly. – msc Oct 03 '18 at 01:32
I down-voted this answer because I was able to build without changing my framework search paths. However after I did that, I realized that my package includes the OpenGL header file so only uses the framework for linking. I tried to reverse the down-vote but clicking the up arrow makes it jump to +1 rather than stopping at 0. – msc Oct 03 '18 at 05:18

score 1 · Answer 5 · edited Nov 07 '19 at 15:20

1

OpenGL in Mojave as of today (October 21, 2018) is bugged. You have to move the glfw window position in order to actually see what it's rendering.

This workaround code inside the rendering loop worked for me:

if(!init)
{
    int x,y;
    glfwGetWindowPos(window,&x, &y);
    glfwSetWindowPos(window,x+1,y);     
    init = true;
}

edited Nov 07 '19 at 15:20

Community

1
1

answered Oct 21 '18 at 13:27

Raydelto Hernandez

2,200
2
16
11

1

Thanks very much for this! I got this working with the mittsu library for Ruby, which wraps glfw. Here's the Ruby code I'm using: https://gist.github.com/ndbroadbent/503f0dc32077a53d32f70673c40df4c7 – ndbroadbent Dec 27 '18 at 21:00
1

One suggestion: You can move the window before the rendering loop to avoid the unnecessary if statement. – synchronizer Mar 01 '19 at 02:37
Unfortunately this code needs to be inside the rendering loop after glfwSwapBuffers(window) and glfwPollEvents() calls have finished their execution. Otherwise it would have no effect. – Raydelto Hernandez Mar 09 '19 at 02:19

score 1 · Answer 6 · answered Oct 26 '18 at 09:43

I am using GLUT and OpenGL. The issue is present on both Xcode 10.0 and 10.1 beta3.

If you resize the window the graphics do appear most of the time.

So I devised a workaround using the reshape callback function. Say I wanted to activate a 1000x1000 window. I activate it with 999x999 and then on reshape I turn it to 1000x1000 as required:

void reshape (int width, int height){
    glutReshapeWindow (1000, 1000);
}

And on main:

int main (int argc, char** argv)
{
    glutInit(&argc,argv);
    glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB);
    glutInitWindowSize( 999,999 );
    glutInitWindowPosition (0.0f, 0.0f);
    glutCreateWindow("example");

    glutReshapeFunc (reshape);
    glutDisplayFunc(draw);
    glutKeyboardFunc(keyboard);
    glutIdleFunc(idle);

    glutMainLoop();
    return 0;
}

Since the reshape callback is triggered before display it is working for now.

I wouldn't recommend using glut though. – synchronizer Oct 27 '18 at 14:53 — synchronizer, Oct 27 '18 at 14:53

score 0 · Answer 7 · answered Sep 29 '18 at 08:00

0

The reason why some OpenGL code failed is because in Mojave, your view is automatically layer-backed. If your code is testing for this condition:

[NSGraphicsContext currentContextDrawingToScreen]

It'll return NO and the code under that condition will not run (i.e.: nothing drawn on the screen).

Unfortunately, you can't setWantsLayer to NO in Mojave either, it'll not work.

answered Sep 29 '18 at 08:00

Kuro

37
4

What would trigger that check in OpenGL though? – synchronizer Sep 29 '18 at 15:09
It is not a check the system triggered, but sometime that code got copied and pasted from Apple's sample code. The fix is not to check currentContextDrawingToScreen when compiling in Xcode 10. – Kuro Oct 03 '18 at 04:51
But I don't think any of us is using Objective-C explicitly. I'm also not using the ide. – synchronizer Oct 03 '18 at 16:02

score 0 · Answer 8 · answered Sep 29 '18 at 21:03

"Fixed" this by downloading Xcode 9.4.1

Compiled in it and got my app with OpenGL view working as it should.

I think it's something with Layer-Backed Views. Because when I scroll my OpenGL view it's became visible under some view.. and flickering. And I see it's drawn correctly behind. But when I stop scroll - it disappears.

score 0 · Answer 9 · answered Nov 06 '18 at 22:52

0

My workaround in GLFW is to call show window in the main draw loop.

 bool needDraw = true;
    if (needDraw) {
        glfwShowWindow(window);
        glfwHideWindow(window);
        glfwShowWindow(window);
        needDraw = false;
    }

answered Nov 06 '18 at 22:52

Nientai Ho

33
3
12

score 0 · Answer 10 · answered Nov 08 '18 at 13:39

0

I also came across this after updating. I'm using glfw. In fact, the created window can show the desired content after resize or move it. I added glfwSetWindowPos(window, 100, 100); in the main loop to move it for a temporary solution.

answered Nov 08 '18 at 13:39

Qian_Lin

1
2

Argha Chakraborty · Answer 11 · 2019-01-11T12:03:15.543

For some cases moving the window coordinate by +1 doesn't work. In that case, we continuously drag the window programmatically until it is rendered and stop the screen by keyboard press. Add it inside the game loop after swapping buffers.

    if (glfwGetKey( window, GLFW_KEY_Q ) == GLFW_RELEASE && !mac_moved){
        int x, y;
        glfwGetWindowPos(window, &x, &y);
        glfwSetWindowPos(window, ++x, y);
    } else {
        mac_moved = true;
    }

Define mac_moved as a static variable somewhere on the top.

static bool mac_moved = false;

Mac Mojave + opengl

11 Answers11

Linked