Screen does no longer update after dismissing the open dialog on OSX using SDL

[lundstroem]

I seem to have a bit of trouble with NFD_OpenDialog on OSX that calls NSOpenPanel which changes the glContext. The same problem occurs with NFD_SaveDialog if you browse more files and then dismiss the dialog.

I've tried various workarounds like this: http://stackoverflow.com/questions/13987148/nsopenpanel-breaks-my-sdl-opengl-app
but I can't get anything to work. Am I missing something? Using SDL version 2.0.3.

/ Harry

[mlabbe]

I am not seeing this problem over here. Tested on Intel-based MBA 2013, Intel-based 2012 Mac Mini and NV-based rMBP 2012.

This may be because my SDL test codebase uses an OpenGL 3.2 context. What context version are you using? Can you supply a minimum, buildable program?

What happens when you create a GL context with: SDL_GL_Context, call the dialog and then set the context back with SDL_GL_MakeCurrent()?

[lundstroem]

I'm using a MacBook Pro (Retina, 15-inch, Mid 2014) with Intel Iris Pro.
OpenGL context I'm using is 2.1.

When creating GL context with SDL_GL_Context, showing the dialog and then setting it again with SDL_GL_MakeCurrent generates no error and with a successful return value, however the screen is black.

Not doing the above results in GL_FRAMEBUFFER_UNDEFINED from glCheckFramebufferStatus when returning from the dialog.

I'll try to get a 3.2 context running and see if that changes anything, and provide a minimal testbuild. Thanks for the suggestions!

/ Harry

[lundstroem]

Unfortunately I couldn't get any other context than 2.1 going for some reason, and I get the same errors as before. Here's a test project https://github.com/lundstroem/nativefiledialog-test

/ Harry

[mlabbe]

I finally ran this program and tested it. It works as expected when I press the 'o' or 's' keys -- the application no longer updates and then continues to update after the dialog is dismissed.

Since there was no SDL framework in your source repository, I had to compile my own. I took the head of Mercurial (today) because the compiled binary at libsdl.org has a bug that crashes Xcode.

I cannot reproduce this.

Output:

---

OpenGL Info
Version: 2.1 NVIDIA-10.2.7 310.41.25f01
Vendor: NVIDIA Corporation
Renderer: NVIDIA GeForce GT 650M OpenGL Engine
Shading: 1.20

---

SDL OpenGL major version:2
SDL OpenGL minor version:1

We compiled against SDL version 2.0.4 ...
But we are linking against SDL version 2.0.4.
open_dialog called
User pressed cancel.
save_dialog called
User pressed cancel.
open_dialog called
User pressed cancel.
open_dialog called
User pressed cancel.
open_dialog called
User pressed cancel.

[lundstroem]

Hey thanks for checking it out. I still have no clue to what could be causing this other than that there's something wrong with my setup (or bug in a lib somewhere), because you can't reproduce it and it appears no one else can either. If you would like to keep the issue open a bit longer I can try with SDL 2.0.4 and see if anything changes. Also if you want you could send me a build of the testproject so we can verify that it works, as to rule out the possibility of users (with the same setup as me) running into the issue.

[mlabbe]

I may not have time to get back to NFD for a few days to archive my project and send it to you. There is no shipping SDL 2.0.4 yet, but if you clone the head of mercurial, build the SDL2 framework and link against that version in your test project, you should be where I was when testing.

I'll leave the issue open for a little while longer.

[lundstroem]

I tested with SDL 2.0.4 and it's the same as before. I made a screen recording of it here: https://youtu.be/5XzUdUTx-7c

[mlabbe]

Hey there, any chance that the fix suggested by velkyel on bug #7 solves your problem, too?

[lundstroem]

Hello! I ran my test project again, and it seems that I can't reproduce the bug anymore (SDL 2.0.3). I noticed that my OpenGL driver got updated to 2.1 INTEL-10.6.20 (old one was 2.1 INTEL-10.2.46) which might have something to do with it. I don't think I could regain focus manually after the dialog was closed, so it could be unrelated.

[mlabbe]

Thanks for reporting back! I am going to close this, but without any suggested fixes.

If someone else comes across this bug please re-report it with full system diagnostics.