Release notes

Release notes for version 3.4

New features in version 3.4

Runtime platform selection

GLFW now supports being compiled for multiple backends and selecting between them at runtime with the GLFW_PLATFORM init hint. After initialization the selected platform can be queried with glfwGetPlatform. You can check if support for a given platform is compiled in with glfwPlatformSupported.

More standard cursors

GLFW now provides the standard cursor shapes GLFW_RESIZE_NWSE_CURSOR and GLFW_RESIZE_NESW_CURSOR for diagonal resizing, GLFW_RESIZE_ALL_CURSOR for omni-directional resizing and GLFW_NOT_ALLOWED_CURSOR for showing an action is not allowed.

Unlike the original set, these shapes may not be available everywhere and creation will then fail with the new GLFW_CURSOR_UNAVAILABLE error.

The cursors for horizontal and vertical resizing are now referred to as GLFW_RESIZE_EW_CURSOR and GLFW_RESIZE_NS_CURSOR, and the pointing hand cursor is now referred to as GLFW_POINTING_HAND_CURSOR. The older names are still available.

For more information see Standard cursor creation.

Mouse event passthrough

GLFW now provides the GLFW_MOUSE_PASSTHROUGH window hint for making a window transparent to mouse input, lettings events pass to whatever window is behind it. This can also be changed after window creation with the matching window attribute.

Support for ANGLE rendering backend selection

GLFW now provides the GLFW_ANGLE_PLATFORM_TYPE init hint for requesting a specific rendering backend when using ANGLE to create OpenGL ES contexts.

Support for custom memory allocator

GLFW now supports plugging a custom memory allocator at initialization with glfwInitAllocator. The allocator is a struct of type GLFWallocator with function pointers corresponding to the standard library functions malloc, realloc and free.

For more information see Custom heap memory allocator.

Support for keyboard access to Windows window menu

GLFW now provides the GLFW_WIN32_KEYBOARD_MENU window hint for enabling keyboard access to the window menu via the Alt+Space and Alt-and-then-Space shortcuts. This may be useful for more GUI-oriented applications.

Caveats for version 3.4

Multiple sets of native access functions

Because GLFW now supports runtime selection of platform (window system), a library binary may export native access functions for multiple platforms. Starting with version 3.4 you must not assume that GLFW is running on a platform just because it exports native access functions for it. After initialization you can query the selected platform with glfwGetPlatform.

Version string format has been changed

Because GLFW now supports runtime selection of platform (window system), the version string returned by glfwGetVersionString has been expanded. It now contains the names of all APIs for all the platforms that the library binary supports.

Joystick support is initialized on demand

The joystick part of GLFW is now initialized when first used, primarily to work around faulty Windows drivers that cause DirectInput to take up to several seconds to enumerate devices.

This change will usually not be observable. However, if your application waits for events without having first called any joystick function or created any visible windows, the wait may never unblock as GLFW may not yet have subscribed to joystick related OS events.

To work around this, call any joystick function before waiting for events, for example by setting a joystick callback.

Tests and examples are disabled when built as a sub-project

GLFW now does not build the tests and examples when it is added as a subdirectory of another CMake project. To enable these, set the GLFW_BUILD_TESTS and GLFW_BUILD_EXAMPLES cache variables before adding the GLFW subdirectory.

set(GLFW_BUILD_EXAMPLES ON CACHE BOOL "" FORCE)
set(GLFW_BUILD_TESTS ON CACHE BOOL "" FORCE)
add_subdirectory(path/to/glfw)

macOS main menu now created at initialization

GLFW now creates the main menu and completes the initialization of NSApplication during initialization. Programs that do not want a main menu can disable it with the GLFW_COCOA_MENUBAR init hint.

CoreVideo dependency has been removed

GLFW no longer depends on the CoreVideo framework on macOS and it no longer needs to be specified during compilation or linking.

Framebuffer transparency requires DWM transparency

GLFW no longer supports framebuffer transparency enabled via GLFW_TRANSPARENT_FRAMEBUFFER on Windows 7 if DWM transparency is off (the Transparency setting under Personalization > Window Color).

Deprecations in version 3.4

Removals in 3.4

GLFW_VULKAN_STATIC CMake option has been removed

This option was used to compile GLFW directly linked with the Vulkan loader, instead of using dynamic loading to get hold of vkGetInstanceProcAddr at initialization. This is now done by calling the glfwInitVulkanLoader function before initialization.

If you need backward compatibility, this macro can still be defined for GLFW 3.4 and will have no effect. The call to glfwInitVulkanLoader can be conditionally enabled in your code by checking the GLFW_VERSION_MAJOR and GLFW_VERSION_MINOR macros.

GLFW_USE_OSMESA CMake option has been removed

This option was used to compile GLFW for the Null platform. The Null platform is now always supported. To produce a library binary that only supports this platform, the way this CMake option used to do, you will instead need to disable the default platform for the target OS. This means setting the GLFW_BUILD_WIN32, GLFW_BUILD_COCOA or GLFW_BUILD_X11 CMake option to false.

You can set all of them to false and the ones that don't apply for the target OS will be ignored.

Support for the wl_shell protocol has been removed

Support for the wl_shell protocol has been removed and GLFW now only supports the XDG-Shell protocol. If your Wayland compositor does not support XDG-Shell then GLFW will fail to initialize.

New symbols in version 3.4

New functions in version 3.4

New types in version 3.4

New constants in version 3.4

Release notes for earlier versions