New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot draw any content initially on 10.14 #1334

Open
coldmoon00 opened this Issue Sep 27, 2018 · 8 comments

Comments

Projects
None yet
8 participants
@coldmoon00

coldmoon00 commented Sep 27, 2018

These codes are most from glfw guide "Getting started". It works fine in macOS 10.13, but it draw nothing from beginning on macOS 10.14. If you move / resize the window manually, your content will write to screen finally.
main.txt

@woc2006

This comment has been minimized.

Show comment
Hide comment
@woc2006

woc2006 Sep 27, 2018

Confirmed.
The same problem for me.

woc2006 commented Sep 27, 2018

Confirmed.
The same problem for me.

@rundbep

This comment has been minimized.

Show comment
Hide comment
@rundbep

rundbep Sep 27, 2018

Same problem here. I tried to work around the problem by doing a resize in my application to see if that would trigger the drawing, but it seems that only a manual resize or move of the window will trigger the drawing.

rundbep commented Sep 27, 2018

Same problem here. I tried to work around the problem by doing a resize in my application to see if that would trigger the drawing, but it seems that only a manual resize or move of the window will trigger the drawing.

@xelatihy

This comment has been minimized.

Show comment
Hide comment
@xelatihy

xelatihy Sep 27, 2018

Same here.

xelatihy commented Sep 27, 2018

Same here.

@kovidgoyal

This comment has been minimized.

Show comment
Hide comment
@kovidgoyal

kovidgoyal Sep 28, 2018

Contributor

glfw just needs to call update() on the NSGLContext a couple of times before swapping the buffers. kovidgoyal/kitty@b82e74f

Contributor

kovidgoyal commented Sep 28, 2018

glfw just needs to call update() on the NSGLContext a couple of times before swapping the buffers. kovidgoyal/kitty@b82e74f

@BrutPitt

This comment has been minimized.

Show comment
Hide comment
@BrutPitt

BrutPitt Sep 29, 2018

Yes, I confirm.
My work around (for now) is to call glfwSetWindowsPos (with different initial position), once, in main loop, ONLY(!) after the first glfwSwapBuffers: move before does not work.

Like this:

            glfwSwapBuffers(getGLFWWnd());

#ifdef __APPLE__
            static bool macMoved = false;

            if(!macMoved) {
                int x, y;
                glfwGetWindowPos(getGLFWWnd(), &x, &y);
                glfwSetWindowPos(getGLFWWnd(), ++x, y);
                macMoved = true;
            }
#endif

BrutPitt commented Sep 29, 2018

Yes, I confirm.
My work around (for now) is to call glfwSetWindowsPos (with different initial position), once, in main loop, ONLY(!) after the first glfwSwapBuffers: move before does not work.

Like this:

            glfwSwapBuffers(getGLFWWnd());

#ifdef __APPLE__
            static bool macMoved = false;

            if(!macMoved) {
                int x, y;
                glfwGetWindowPos(getGLFWWnd(), &x, &y);
                glfwSetWindowPos(getGLFWWnd(), ++x, y);
                macMoved = true;
            }
#endif
@kovidgoyal

This comment has been minimized.

Show comment
Hide comment
@kovidgoyal

kovidgoyal Sep 29, 2018

Contributor

you dont need to do that, just call the update method on the nsglcontext object, as I demonstrated in the commit I linked to earlier.

Contributor

kovidgoyal commented Sep 29, 2018

you dont need to do that, just call the update method on the nsglcontext object, as I demonstrated in the commit I linked to earlier.

@yairchu

This comment has been minimized.

Show comment
Hide comment
@yairchu

yairchu Oct 4, 2018

I noticed that the Gears example works fine, and stops working when removing glfwWindowHint(GLFW_TRANSPARENT_FRAMEBUFFER, GLFW_TRUE); from it. So I guess that making transparent buffers could also be a work-around.

yairchu commented Oct 4, 2018

I noticed that the Gears example works fine, and stops working when removing glfwWindowHint(GLFW_TRANSPARENT_FRAMEBUFFER, GLFW_TRUE); from it. So I guess that making transparent buffers could also be a work-around.

@yairchu

This comment has been minimized.

Show comment
Hide comment
@yairchu

yairchu Oct 4, 2018

Here's a workaround that worked for me:

Use glfwWindowHint(GLFW_TRANSPARENT_FRAMEBUFFER, GLFW_TRUE); before creating the window.

If the application results with transparency in the frame buffer and background is showing through the window, clear your frame buffer's alpha (using glColorMask, glClearColor, and glClear) before swapping buffers.

yairchu commented Oct 4, 2018

Here's a workaround that worked for me:

Use glfwWindowHint(GLFW_TRANSPARENT_FRAMEBUFFER, GLFW_TRUE); before creating the window.

If the application results with transparency in the frame buffer and background is showing through the window, clear your frame buffer's alpha (using glColorMask, glClearColor, and glClear) before swapping buffers.

@elmindreda elmindreda changed the title from [macOS]GLFW can't draw any content automatically from beginning on macOS 10.14 to Cannot draw any content initially on 10.14 Oct 4, 2018

a3f added a commit to a3f/raylib that referenced this issue Oct 7, 2018

core: workaround window not being rendered till moved on macOS Mojave
Apple ought to fix their OpenGL implementation, but with OpenGL now
deprecated this might not happen.

This has been reported upstream in GLFW in glfw/glfw#1334.
The workaround comes from kovidgoyal/kitty@b82e74f

This also fixes the HiDPI (Retina) scaling issues reported in #497,
so the workaround is enabled anywhere __APPLE__ is defined.

a3f added a commit to a3f/raylib that referenced this issue Oct 7, 2018

core: workaround window not being rendered till moved on macOS Mojave
Apple ought to fix their OpenGL implementation, but with OpenGL now
deprecated this might not happen.

This has been reported upstream in GLFW in glfw/glfw#1334.
The workaround comes from kovidgoyal/kitty@b82e74f

This also fixes the HiDPI (Retina) scaling issues reported in #497,
so the workaround is enabled anywhere __APPLE__ is defined.

BlackMATov added a commit to enduro2d/enduro2d that referenced this issue Oct 8, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment