This page tries to answer some of the most commonly asked questions that we have received from GLFW users. If you have any questions that are not answered here, feel free to contact us.
GLFW is a framework intended to help programmers to develop OpenGL applications. The idea is to provide an API (Application Program Interface) that is easy to use, even for an OpenGL beginner writing small programs, yet powerful enough to be used in larger projects.
The reason that a framework like GLFW is needed, is that OpenGL by itself does not provide any mechanisms for handling windows, user input, timing etc. Here is a quote from the OpenGL 1.4 Specification (chapter 2, first paragraph):
"OpenGL is concerned only with rendering into a frame-buffer (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."
In this context, GLFW matches the description other mechanisms quite well.
The primary objective of GLFW is that it should handle most of the operating system specific tasks that are required for an OpenGL application, which includes opening and managing a window (normal or fullscreen) and reading keyboard and mouse input. Further functionality of GLFW provides a high resolution timer, multi threading support, OpenGL extension handling, joystick input, and more.
There are already several toolkits available for aiding OpenGL development. The most widespread is GLUT, which unfortunately is getting quite old and is not actively updated anymore. When I first started out with OpenGL I tried using GLUT, which did not quite suite my needs, and I also tried using pure win32 programming, which quickly got very messy. I also looked at some other toolkits, but they were not portable and/or designed for C++ only.
I realized that a new toolkit was badly needed, which could fulfill the following requirements:
Today GLFW meets those requirements - and many more.
GLFW is designed to be as portable as possible, and the code has been written with portability as a key design driver. An updated list of platforms currently supported can be found on our platforms page.
GLFW is by design not...
This choice was made for several reasons. One reason is that the glX interface (under X11) only provides means for selecting the size of individual color components. Another reason is that terms like "color bits" and "BPP" (bits per pixel) are not very well defined. Sometimes they include the alpha component, sometimes not, and sometimes they simply refer to the memory alignment of pixels on the screen (which is only vaguely related to the number of bits used for color).
The red/green/blue bits notation may feel slightly odd for some. Especially the PC gaming community have grown very familiar with the terms "16 BPP" and "32 BPP", which roughly indicate "low" and "high" color resolution, but in the context of OpenGL, these terms are not very relevant (not to mention unportable). In fact, in 16 BPP mode, an nVidia GeForce 256 card uses 32 bits per pixel (5+6+5 for color, and 16 for the depth buffer), and in 32 BPP mode, it uses 64 bits per pixel (8+8+8 for color, 8 for alpha, 8 for stencil and 24 for the depth buffer).
Some cards do not behave well when the video mode is changed once the window has been opened. The most important reason though is that under the X Window System it is only possible to set the color depth of an OpenGL window at the time of creating the OpenGL context (i.e. when opening the window).
GLFW 2.1 and later versions support limited video mode control of an already opened window through the glfwSetWindowSize() function (see the manual for more information). It makes it possible to change the video mode to another resolution, but with maintained color depth.
Through the glfwReadImage and glfwLoadTexture2D functions, GLFW supports the Truevision Targa version 1 (TGA) file format.
Supported pixel formats are: 8-bit gray-scale, 24-bit RGB, 32-bit RGBA and colormap (24/32-bit colors). Note that colormap images are always converted to 24-bit or 32-bit true color. Files that are RLE encoded (compressed) are also supported.
It is very unlikely. The reason is that sound is a very complex subject that is not easily included in an API such as GLFW. The idea with GLFW is that it should be compact, and additional functionality such as sound output is much better handled by one of the several audio toolkits already available (see the links section).
It is very unlikely (see the notes about sound support). There are already several competent font rendering toolkits available for OpenGL (see the links section).
It is not planned, but it is definitely not ruled out yet.
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 Home Page for more information about 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 the following languages: Afrikaans, Basque, Catalan, Danish, Dutch, English, Faeroese, Finnish, French, Galician, German, Icelandic, Irish, Italian, Norwegian, Portuguese, Spanish and Swedish.
Here is an ISO 8859-1 FAQ.
No, not 100%. The threading part of the GLFW API (threads, mutexes and condition variables) is thread safe, as is the glfwSleep function. Other functions are NOT thread safe, and calling them from different threads may result in an inconsistent GLFW state.
It is recommended that all GLFW calls (except for thread management and synchronization calls) are made from a single thread, which should not be a big problem since only a single window is supported. This method is also compatible with the future directions of GLFW.
Future versions of GLFW will be thread safe, and have support for per thread window contexts (e.g. glfwGetWindowSize will return the size for the window that is currently bound to the calling thread).
Yes, you can. The function 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(GLFW_KEY_LCTRL) or glfwGetKey(GLFW_KEY_RCTRL), or both).
Please see our features page for a list of currently supported C/C++ compilers.
The binary distribution contains precompiled libraries for all of the above mentioned compilers.
Moreover, you can use GLFW from:
If your compiler is not supported, do not hesitate to contact us. It may not be difficult at all to add support for it - GLFW is designed to be compiler friendly, and the API is designed so that the Windows DLL version of GLFW should be easy to use from many different languages.
If you get errors like this one when you try to compile a GLFW based program, you have not linked your program correctly:
error LNK2001: unresolved external symbol _glfwGetWindowParam
(Example from Microsoft Visual C++)
How to do this is described in the readme.html file that is
included in the GLFW source & binary distributions. Here is the short
version:
When linking a program under Windows that uses the static version of GLFW, you must also link with the following libraries: opengl32, user32 and kernel32. Some of these libraries may be linked with by default by your compiler. In the table below you can see the minimum required link options for each supported Windows compiler (you may want to add other libraries as well, such as glu32):
| Compiler | Link options |
| Borland C++ Builder | glfw.lib opengl32.lib |
| Cygwin | -lglfw -lopengl32 |
| LCC-Win32 | glfw.lib opengl32.lib |
| Microsoft Visual C++ | glfw.lib opengl32.lib user32.lib |
| MinGW32 | -lglfw -lopengl32 |
| Open Watcom | glfw.lib opengl32.lib user32.lib |
When linking a program under Windows that uses the DLL version of GLFW, the only library you need to link with for GLFW to work is glfwdll (glfwdll.lib or -lglfwdll, depending on your compiler). For programs that use glfw.dll, each source file that includes <GL/glfw.h> needs GLFW_DLL to be defined. Either use -DGLFW_DLL as a compiler option or #define GLFW_DLL before including <GL/glfw.h>. Of course, you also need to place glfw.dll in your exe directory (or Windows system folder).
Simple answer: the best available! Under Windows, GLFW supports three timers: RDTSC (CPU cycle counter, available on Pentium class CPUs and later), QueryPerformanceCounter and timeGetTime. RDTSC is the first choice, but it is not available on older (486) and non-x86 computers, and does not work in multi processor systems. QueryPerformanceCounter is the second choice, and it should be available on most modern hardware. timeGetTime is used when all else fails. Below is a table listing an estimate of the resolution of each timer class:
| RDTSC | QueryPerformanceCounter | timeGetTime | |
| Resolution | ~0.5-10 ns | ~1 us | ~1-10 ms |
Note: RDTSC is only supported when GLFW is compiled with GCC (MinGW32/Cygwin), LCC-Win32 or Microsoft Visual C++. The free Borland C++ Builder compiler does not support inline assembly language natively. Thus GLFW does not support RDTSC when compiled with the Borland C++ Builder compiler.
Simple answer: the best available! Under Unix and Unix-like systems, GLFW supports four timers: RDTSC (CPU cycle counter, available on Pentium class x86 CPUs and later), gettimeofday, gethrtime and CLOCK_SGI_CYCLE. On x86 architectures, RDTSC is the first choice, but it is not available on older (486) computers, and does not work in multi processor systems. On Sun/Solaris systems, gethrtime is used, and on SGI/IRIX systems, CLOCK_SGI_CYCLE timing is used. On other systems, gettimeofday is used, which should provide accurate timing on most modern systems. Below is a table listing an estimate of the resolution of each timer class:
| RDTSC | CLOCK_SGI_CYCLE | gethrtime | gettimeofday | |
| Resolution | ~0.5-10 ns | ~10-100 ns | ~100-300 ns | typically <1 ms |
Note: RDTSC is only supported when GLFW is compiled with GCC.
Presently, there are several limitations. Here is a list of some (all?) of them:
Apart from these limitations, the AmigaOS port of GLFW works almost identically to the other GLFW implementations. In particular, the threading package works quite well, mimicing the behaviour of a POSIX compatible pthread implementation.
timer.device / ReadEClock(). This should give a resolution in the order of 1 microsecond (or about 1/710000 s).