GLFW is a small C library that lets you create and manage an OpenGL context and its associated window, enumerate and change display modes, as well as handle inputs such as keyboard, mouse, joystick, clipboard and time.
GLFW provides a thin, multi-platform abstraction layer, primarily for applications whose sole graphics output is through the OpenGL API. While GLFW is very useful when developing multi-platform OpenGL applications, single-platform developers can also benefit from avoiding having to deal with kludgy platform-specific APIs.
The reason that libraries like GLFW are needed is that OpenGL by itself does not provide any mechanisms for creating the necessary context, managing windows, user input, timing etc. As stated in the OpenGL 3.1 Specification (chapter 2, first paragraph):
OpenGL is concerned only with rendering into a framebuffer (and reading values stored in that framebuffer). There is no support for other peripherals sometimes associated with graphics hardware, such as mice and keyboards. Programmers must rely on other mechanisms to obtain user input.
GLFW matches the description of other mechanisms quite well.
GLFW is by design not
GLFW_ICONresource at window creation.
There are several other libraries available for aiding OpenGL development. The most common ones are freeglut, an Open Source implementation of GLUT, and SDL.
However, freeglut is mostly concerned with providing a stable clone of GLUT, while SDL is too large for some people and has never had OpenGL as its main focus.
We therefore believe that there is room for a lightweight, modern library for managing OpenGL contexts, windows and input.
Currently, GLFW supports Windows, OS X and Unix-like operating systems with the X Window System, such as Linux and FreeBSD.
GLFW is designed to be as portable as possible, and the code has been written with portability in mind.
This question likely stems from the original version of the
GLX_ARB_create_context extensions, which stated that the old context creation mechanism would be limited to OpenGL version 2.1. However, this is no longer the case and the specifications have been updated accordingly.
GLFW 2.6 and earlier use only the older context creation mechanism, which on Windows and X11 may return contexts of any version, however new, provided they implement the
ARB_compatibility extension. Most modern drivers do this.
Explicit creation of OpenGL contexts of version 3.0 and above on Windows and X11, including profiles and flags, is supported by GLFW 2.7 and later.
However, OS X did not support OpenGL 3.0 or later at the time that GLFW 2.7 was released, and the support that Apple has since added only includes forward-compatible OpenGL 3.2 core profile contexts. Additionally, creating such contexts requires new code, so older versions of GLFW cannot create OpenGL 3.0 contexts on OS X.
The first version to support creation of OpenGL 3.2 contexts on OS X Lion and later was GLFW 2.7.2.
In short, because it more closely matches the way most platforms describe OpenGL-capable pixel formats, which in the past actually mattered.
Today, when nearly everyone just asks for 24-bit color and gets it, it matters less. It does, however, make the API slightly more future-proof, as the values specified can be passed nearly unmodified to the window system.
This doesn’t, of course, prevent you from presenting the familiar, single value color depths to the user.
There is limited support for mode switching in the form of
glfwSetWindowSize. In full screen mode this will change the video mode to that closest matching the current mode, with refresh mode and color depth preserved.
However, if you are looking for an OpenGL-like API for sound, have a look at OpenAL.
There are already several competent font rendering toolkits available for OpenGL, none of which require integration with a context or window management library.
Not right now.
The main issue keeping this from being added is the lack of a standard, Unicode-enabled UI toolkit on Unix-like systems such as Linux and FreeBSD. Depending on, say, Gtk+, would therefore introduce a dependency on a huge amount of code not necessarily present on the user’s machine.
As there is no reason why message box code has to be integrated into GLFW, it is better to leave that functionality to a separate library.
Unicode (sometimes referred to as ISO 10646), is a character coding standard that encodes virtually every character from every written language in the world into a common character set. It is gaining acceptance worldwide, and today most platforms, computer languages and APIs have some sort of support for Unicode (GLFW now being one of them).
Visit The Unicode Consortium for more information about Unicode.
See also Wikipedia on Unicode.
ISO 8859-1 (also known as Latin 1), is a very limited subset of the Unicode character set. It represents the lowest 0-255 codes of the Unicode character set, and can thus be coded with a single byte. Character codes 32-126 are equal to the US-ASCII character set. However, with the additional character codes 160-255, ISO 8859-1 is able to support many European languages.
See also Wikipedia on ISO 8859-1.
Some parts are, specifically those needed to allow rendering from secondary threads.
Yes, you can.
glfwGetKey lets you check the state of any keyboard key (including special keys). You can even call the function from within a callback function, which makes it possible to check for things like Ctrl+F3 key events (when you get a
GLFW_KEY_F3 key press event, check the state of the left or right CTRL key with
glfwGetKey(window, GLFW_KEY_LEFT_CONTROL) or
glfwGetKey(window, GLFW_KEY_RIGHT_CONTROL), or both).
On Windows, the
QueryPerformanceCounter API is used if available, with
timeGetTime as a fallback.
On OS X, the Mach
mach_absolute_time time source is used.
On Unix-like operating systems using the X11 port, the POSIX
CLOCK_MONOTONIC time source is used if available, with
gettimeofday as a fallback.
On Windows, plain Win32 is used for window and input management, and WGL (with extensions) is used to create contexts.
On OS X, Cocoa is used for window and input management, and NSOpenGL for context creation.
On Unix-like systems using the X Window System, the Xlib API is used for window and input management, the XRandR or XF86VidMode extension (if available) for display mode management, and GLX (with extensions) for context creation.
There is also an experimental EGL backend that works with the Win32 and Xlib APIs.
GLFW does not provide any version of either
glfw3.h header file includes the versions already present in your development environment.
However, if you are using Windows, you cannot get anything newer than OpenGL 1.2 without using extensions. As the extension management in GLFW is very rudimentary, we recommend that you use a dedicated extension loading library such as GLEW.
GLFW does not exist between your code and OpenGL. Think instead of GLFW as connecting your code to OpenGL and then getting out of the way. If you get incorrect rendering results, it is therefore most likely due to errors in your code, the OpenGL implementation or both.
The OpenGL.org wiki has an extensive article on common mistakes that may be able to help you locate the problem.
Yes, as long as you include the GLEW header before the GLFW one. The GLEW header defines all the necessary magic macros to make sure the
gl.h that GLFW attempts to include doesn’t interfere.
You cannot use regular methods as callbacks, as GLFW is a C library and doesn’t know about objects and
this pointers. If you wish to receive callbacks to a C++ object, use static methods or regular functions as callbacks, store the pointer to the object you wish to call as the user pointer for the window and use it to call methods on your object.
Currently, GLFW releases are tested with Visual C++ 2010, 2012 and 2013, standalone MinGW, MinGW with MSYS, and the Cygwin packages for MinGW.
The Windows binary distribution of GLFW contains pre-compiled libraries for all of the compilers mentioned above.
If your compiler is not supported, please don’t hesitate to contact us.
See the Building programs that use GLFW guide for details on how to compile and link programs on various platforms.
Modern graphics drivers have settings that allow users to override an application’s request for (among other things) swap interval. If such a setting is enabled,
glfwSwapInterval will have no effect.
Swap interval setting is also by default disabled by GLFW on Windows Vista and later version when using DWM (Aero), as setting the swap interval there leads to severe jitter on some hardware. You can forcibly enable this with a compile-time option. See the Compiling GLFW guide for details.
The only OpenGL 3.x and 4.x contexts currently supported by OS X are forward-compatible, core profile contexts. The supported versions are 3.2 on 10.7 Lion and 3.3 and 4.1 on 10.9 Mavericks. In all cases, your GPU needs to support the specified OpenGL version for context creation to succeed.
To create either an OpenGL 3.2 or later context, you should set the following hints:
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 2); glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE); glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
This will give you a context for the highest version of OpenGL greater than or equal to 3.2 that is supported by your OS and GPU. This works because no features were deprecated between OpenGL 3.2 and 4.1, making forward-compatible OpenGL 4.1 backards-compatible with 3.2. If the requested version is not supported, window creation will fail.
If your code requires OpenGL 3.3 or 4.1, you can specify those versions instead, as well as any valid OpenGL version in between.