When creating a window on OSX 10.9, the framebuffer size is by default the size of the screen. If the executable is within an 'app' folder structure (eg test.app/Contents/MacOS/test) then the framebuffer size is the window size, which is the expected behavior.
So, can we revert to glfw2 functionality where an executable doesn't need to be in an 'app' structure to have framebuffer size = window size?
This is urgent as this is blocking many projects we work on to be released.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ok that works but that still doesn't explain why an executable in a Mac bundle would use setWantsBestResolutionOpenGLSurface:NO while outside of a bundle it uses YES.
I think by default it should be NO so that we have the same behavior in or outside of a bundle. And a window hint could be used to select the best resolution.
This way, it will be consistent with glfw2 behavior too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Retina support is the proper thing to have in very nearly all cases. If you need to render some parts at a lower resolution, use an FBO for those parts. Any Mac that has a Retina display supports FBOs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"proper thing to have in nearly all cases".
Nope not at all. That's probably why in bundles Apple forces to non-retina resolution.
So GLFW, in command-line, non-bundles, should not force to retina. It should do like Apple does in its bundles.
Unless you say all GLFW executables should be bundled (which would be a terrible mistake), GLFW should use setWantsBestResolutionOpenGLSurface:NO to be consistent with Apple bundle execution model for unbundled executables.
I maintain this is a GLFW bug which, for now, forces us to release with a modified glfw3 library and made us waste many many days...this is bad bad bad!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Retina display support is disabled by default by OS X because of backward compatibility. I can guarantee that Apple hasn't deliberately enabled it for unbundled applications. Rather, unbundled GUI applications are always somewhat broken. Every new version of OS X fixes some bugs and adds others. For example, on 10.9 menus for unbundled applications broke.
Apple recommends that GUI applications have bundles. This is the recommendation I'm passing on. This is what is used by Apple and by far the most of ISVs, and thus what gets tested. It is also what users of OS X expect.
GLFW 3.1 adds a compile-time option to disable Retina support, for those rare occasions where it's needed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When creating a window on OSX 10.9, the framebuffer size is by default the size of the screen. If the executable is within an 'app' folder structure (eg test.app/Contents/MacOS/test) then the framebuffer size is the window size, which is the expected behavior.
So, can we revert to glfw2 functionality where an executable doesn't need to be in an 'app' structure to have framebuffer size = window size?
This is urgent as this is blocking many projects we work on to be released.
If you don't want support for Retina displays, remove the call to
NSView setWantsBestResolutionOpenGLSurface:.ok that works but that still doesn't explain why an executable in a Mac bundle would use setWantsBestResolutionOpenGLSurface:NO while outside of a bundle it uses YES.
I think by default it should be NO so that we have the same behavior in or outside of a bundle. And a window hint could be used to select the best resolution.
This way, it will be consistent with glfw2 behavior too.
You will have to ask Apple why unbundled applications behave inconsistently.
Retina support is the proper thing to have in very nearly all cases. If you need to render some parts at a lower resolution, use an FBO for those parts. Any Mac that has a Retina display supports FBOs.
"proper thing to have in nearly all cases".
Nope not at all. That's probably why in bundles Apple forces to non-retina resolution.
So GLFW, in command-line, non-bundles, should not force to retina. It should do like Apple does in its bundles.
Unless you say all GLFW executables should be bundled (which would be a terrible mistake), GLFW should use setWantsBestResolutionOpenGLSurface:NO to be consistent with Apple bundle execution model for unbundled executables.
I maintain this is a GLFW bug which, for now, forces us to release with a modified glfw3 library and made us waste many many days...this is bad bad bad!
Retina display support is disabled by default by OS X because of backward compatibility. I can guarantee that Apple hasn't deliberately enabled it for unbundled applications. Rather, unbundled GUI applications are always somewhat broken. Every new version of OS X fixes some bugs and adds others. For example, on 10.9 menus for unbundled applications broke.
Apple recommends that GUI applications have bundles. This is the recommendation I'm passing on. This is what is used by Apple and by far the most of ISVs, and thus what gets tested. It is also what users of OS X expect.
GLFW 3.1 adds a compile-time option to disable Retina support, for those rare occasions where it's needed.