There is a seemingly unavoidable race condition when waiting for data on
the X11 display connection, as long as any other thread is also making
Xlib calls. The event data we are waiting for could be read by the
other thread as part of looking for the reply to its request, before our
poll has begun.
This commit replaces the X11 event sent by glfwPostEmptyEvent with
writing to an unnamed pipe. The race condition remains if other Xlib
calls are made on other threads, but glfwPostEmptyEvent should now be
race-free.
This commit is based on work by pcwalton, OlivierSohn, kovidgoyal and
joaodasilva.
Closes #2033
Related to #379
Related to #1281
Related to #1285
(cherry picked from commit cd22e28495
)
6.9 KiB
GLFW
Introduction
GLFW is an Open Source, multi-platform library for OpenGL, OpenGL ES and Vulkan application development. It provides a simple, platform-independent API for creating windows, contexts and surfaces, reading input, handling events, etc.
GLFW natively supports Windows, macOS and Linux and other Unix-like systems. On Linux both X11 and Wayland are supported.
GLFW is licensed under the zlib/libpng license.
You can download the latest stable release
as source or Windows binaries, or fetch the latest
branch from GitHub. Each
release starting with 3.0 also has a corresponding annotated
tag with source and binary archives.
The documentation is available online and is included in all source and binary archives. See the release notes for new features, caveats and deprecations in the latest release. For more details see the version history.
The master
branch is the stable integration branch and should always compile
and run on all supported platforms, although details of newly added features may
change until they have been included in a release. New features and many bug
fixes live in other branches until
they are stable enough to merge.
If you are new to GLFW, you may find the tutorial for GLFW 3 useful. If you have used GLFW 2 in the past, there is a transition guide for moving to the GLFW 3 API.
GLFW exists because of the contributions of many people around the world, whether by reporting bugs, providing community support, adding features, reviewing or testing code, debugging, proofreading docs, suggesting features or fixing bugs.
Compiling GLFW
GLFW itself requires only the headers and libraries for your OS and window system. It does not need the headers for any context creation API (WGL, GLX, EGL, NSGL, OSMesa) or rendering API (OpenGL, OpenGL ES, Vulkan) to enable support for them.
GLFW supports compilation on Windows with Visual C++ 2010 and later, MinGW and MinGW-w64, on macOS with Clang and on Linux and other Unix-like systems with GCC and Clang. It will likely compile in other environments as well, but this is not regularly tested.
There are pre-compiled Windows binaries available for all supported compilers.
See the compilation guide for more information about how to compile GLFW yourself.
Using GLFW
See the documentation for tutorials, guides and the API reference.
Contributing to GLFW
See the contribution guide for more information.
System requirements
GLFW supports Windows XP and later and macOS 10.8 and later. Linux and other Unix-like systems running the X Window System are supported even without a desktop environment or modern extensions, although some features require a running window or clipboard manager. The OSMesa backend requires Mesa 6.3.
See the compatibility guide in the documentation for more information.
Dependencies
GLFW itself depends only on the headers and libraries for your window system.
The (experimental) Wayland backend also depends on the extra-cmake-modules
package, which is used to generate Wayland protocol headers.
The examples and test programs depend on a number of tiny libraries. These are
located in the deps/
directory.
- getopt_port for examples with command-line options
- TinyCThread for threaded examples
- glad2 for loading OpenGL and Vulkan functions
- linmath.h for linear algebra in examples
- Nuklear for test and example UI
- stb_image_write for writing images to disk
The documentation is generated with Doxygen if CMake can find that tool.
Reporting bugs
Bugs are reported to our issue tracker. Please check the contribution guide for information on what to include when reporting a bug.
Changelog
- [Cocoa] Bugfix:
kUTTypeURL
was deprecated in macOS 12.0 (#2003) - [X11] Bugfix: Dynamic loading on OpenBSD failed due to soname differences
- [X11] Bugfix: Waiting for events would fail if file descriptor was too large (#2024)
- [X11] Bugfix: Joystick events could lead to busy-waiting (#1872)
- [X11] Bugfix:
glfwWaitEvents*
did not continue for joystick events - [X11] Bugfix:
glfwPostEmptyEvent
could be ignored due to race condition (#379,#1281,#1285,#2033) - [Wayland] Added support for key names via xkbcommon
- [Wayland] Bugfix: Key repeat could lead to a race condition (#1710)
- [Wayland] Bugfix: Activating a window would emit two input focus events
- [Wayland] Bugfix: Disable key repeat mechanism when window loses input focus
- [Wayland] Bugfix: Window hiding and showing did not work (#1492,#1731)
- [Wayland] Bugfix: A key being repeated was not released when window lost focus
- [Wayland] Bugfix: Showing a hidden window did not emit a window refresh event
- [Wayland] Bugfix: Full screen window creation did not ignore
GLFW_VISIBLE
- [Wayland] Bugfix: Some keys were reported as wrong key or
GLFW_KEY_UNKNOWN
- [Wayland] Bugfix: Text input did not repeat along with key repeat
- [GLX] Bugfix: Context creation failed if GLX 1.4 was not exported by GLX library
Contact
On glfw.org you can find the latest version of GLFW, as well as news, documentation and other information about the project.
If you have questions related to the use of GLFW, we have a
forum, and the #glfw
IRC channel on
Libera.Chat.
If you have a bug to report, a patch to submit or a feature you'd like to request, please file it in the issue tracker on GitHub.
Finally, if you're interested in helping out with the development of GLFW or porting it to your favorite platform, join us on the forum, GitHub or IRC.