glfwSwapBuffers may be called by any thread but NSWindow may not.
Bug introduced by c3ca88055f and reported
by @crujose.
(cherry picked from commit 949275bbed)
If the application is not linked against the Vulkan loader and relies on
a third-party loader library or glfwGetInstanceProcAddress, then our
call to dlopen will fail without a custom dyld environment variable.
This adds a fallback of looking in the directory of the main executable,
which matches the bundle structure recommended by the Vulkan SDK, making
that finally work out of the box for fully dynamic loading.
(cherry picked from commit 7da87aaae7)
This removes the final dependency on CoreVideo, using a display link to
get the refresh rate of monitors where Core Graphics report a refresh
rate of zero. Instead we now query the I/O registry directly, similarly
to what the display link does at creation.
Thanks to @OneSadCookie for pointers to this solution.
(cherry picked from commit 4ec7daf3e9)
The display link query is not specific to any particular display mode
and so only needs to be done once.
The next step is to replace the display link altogether by querying
IOKit directly, which is what the display link does.
(cherry picked from commit b4a8eb9b19)
This solution of one display link per window is far from ideal but is
still better than no solution.
As a side-effect this fixes swap interval breaking being ignored for
occluded windows on earlier versions of macOS.
Fixes#680.
Fixes#1337.
Related to #1417.
Fixes#1435.
This is another small step towards having GLFW play nice with other
toolkits sharing the same process, including AppKit.
Any macOS platform function that touches Cocoa must now wrap itself in
an autoreleasepool block.
Since GLFW no longer provides an autoreleasepool outside of its
functions, THIS MAY BREAK EXISTING CODE MIXING GLFW AND COCOA. Sorry!
Please add your own autoreleasepool blocks as needed.
Fixes#1107.
Closes#1114.
The application delegate needs to be set at init to receive monitor
events before window creation. Menu creation is moved to
applicationWillFinishLaunching: to play nicer with other toolkits in the
same process.
Related to #1317.
This removes the GLFW NSApplication subclass as a step towards better
coexistence with other libraries that touch Cocoa.
This moves application object creation to platform init to allow event
processing before window creation.
Related to #1317.
Allow window creation despite video mode setting failure.
Video mode setting failure is ignored the rest of the time and the
desired video mode has never been a hard constraint anyway.
This adds glfwGetWindowContentScale and glfwGetMonitorContentScale for
querying the recommended drawing scale factor for DPI-aware rendering.
Parts of this patch are based on code by @ferreiradaselva.
Fixes#235.
Fixes#439.
Fixes#677.
Fixes#845.
Fixes#898.
When cursor isn't in normal mode and should be hidden, use [NSCursor hide]
method instead of setting it to blank image. This should prevent
situations when hidden cursor becomes visible after system notification
was shown.
Fixes#971.
Closes#1028.
Inclusion of internal headers is already both centralized and follows
strict rules. Inclusion guards are both an unneccessary maintenance
burden and may hide inclusion order bugs.
This adds basic support for MoltenVK, a Vulkan implementation on top of
Metal, on macOS 10.11 and later. It looks for MoltenVK in the process
via RTLD_DEFAULT symbol lookup if _GLFW_VULKAN_STATIC is disabled.
glfwCreateWindowSurface now creates and sets a CAMetalLayer for the
window content view, which is required for MoltenVK to function.
You must help CMake find MoltenVK for the Vulkan test to be built.
Fixes#870.
Due to Wayland, shared code cannot rely on cursor positioning being
supported by the underlying platform.
This implicitly fixes#617 as it moves cursor centering into
_glfwPlatformSetCursorMode, thus separating it from the stale value of
_glfw.cursorWindow.
Fixes#617.
