A C++ binding for the OpenGL API, generated using the gl.xml specification.

glbinding leverages modern C++11 features like enum classes, lambdas, and variadic templates, instead of relying on macros;
all OpenGL symbols are real functions and variables.
It provides type-safe parameters, per feature API header, lazy function resolution, multi-context and multi-thread support, global and local function callbacks, meta information about the generated OpenGL binding and the OpenGL runtime, as well as tools and examples for quick-starting your projects.
Based on the OpenGL API specification (gl.xml) glbinding is generated using python scripts and templates that can be easily adapted to fit custom needs.

Code that is written using a typical C binding for OpenGL, e.g., GLEW, is fully compatible for the use with glbinding and causes no significant impact on runtime performance (see compare example): just replace all includes to the former binding, replace the initialization code and use the appropriate API namespace, e.g., gl.

Install Instructions

glbinding is available for different platforms using different distribution channels.
You can either download the source and manually compile it or use one of the pre-compiled releases of this repository.
For systems providing package managers, we generally strive for packages in these package managers.

Windows

The various glbinding packages can be installed either by downloading an installer, e.g., the x64 installer for glbinding v2.1.1 for Microsoft Visual Studio 2015, or downloading and extracting one of the precompiled archives, e.g. runtime,
examples,
dev, and
tools.
Since lately, glbinding is also available on vcpkg with more recent releases:

Ubuntu

glbinding is provided on Ubuntu using PPAs and in Ubuntu universe since Artful Aardvark. We maintain our own PPA for most recent releases. For Ubuntu 16.04 (xenial), 17.10 (artful), and 18.04 (bionic) use the standard PPA, for Ubuntu 14.04 (trusty) use the backports PPA.
Using the current PPA as example, the following lines install glbinding including the GLFW examples:

Debian-based Systems

glbinding is available for Debian 9 (Stretch), 10 (Buster) and Sid. Install it using apt-get install glbinding.
For advanced use, download the source code and commence building from source.

Build Instructions

Prerequisites and Dependencies

The only mandatory run-time dependencies of glbinding are the STL of the used compiler and an OpenGL driver library, dynamically linked with your application.
Building glbinding from source has several mandatory and optional dependencies:

CMake 3.0 or higher for building glbinding from source (mandatory for any build from source)

Configure glbinding with your preferred or default generator, e.g., for Visual Studio 2015 in x64 use
(note: some IDEs have integrated support for CMake projects, e.g., Qt Creator, and allow you to skip the manual project configuration):

> cmake .. -G "Visual Studio 15 2017 Win64"

In order to compile the project, either use you favorite Editor/IDE with the created project or use CMake as follows:

> cmake --build .

Generating/Updating the Binding Manually

Tips for Linking

We suggest using the build system of glbinding for a smooth integration: CMake
For it, glbinding provides a find configuration script that should be installed into your system or at least accessible by CMake.
In the projects CMakeLists.txt, add one of the following lines:

find_package(glbinding QUIET) # if you want to check for existencefind_package(glbinding REQUIRED) # if it is really required in your project

Basic Example

The following examples are tailored for use with glbinding 3.0 and above.

glbinding has to be initialized once on the active OpenGL context you want to use glbinding with. For initialization, a callback for function pointer resolution must be passed, which your context creation API should provide.
In the most basic case, you call glbinding::initialize once:

Features

The following examples are tailored for use with glbinding 3.0 and above.

Type-Safe Parameters

The original OpenGL API provides several concepts in their interface, namely functions, booleans, bitfields, enums, as well as special values and basic types but mostly does not differentiate between these types.
Hence, actual knowledge about each function and its parameters is required; there is no way for a basic code assistance.
As glbinding differentiates between all these types, IDEs and compilers can detect wrong usages of the OpenGL API.

One example is the passing of a named constant in places where a bit combination is expected:

Compilation-Centered Header Design

C++ strictly separates interface from implementation.
For improving the compilation time of a program or system written in C++ forward declarations of types are commonly used and includes of unnecessary symbols are omitted.

For an interface of a library, class, or module providing OpenGL related functionality, it is likely that only the type information of OpenGL is needed, not actual functions or constants usually required for implementation.
In addition to the customary all-in-one header gl.hglbinding also provides specialized headers:

There is one additional header that provides all extensions and provide them as an enumeration in terms of C++ enums.

#include<glbinding/gl/extension.h>

Feature-Centered Header Design

The OpenGL API is iteratively developed and released in versions, internally (for the API specification) named features.
The latest feature/version of OpenGL is 4.6.
The previous version are 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 2.0, 2.1, 3.0, 3.1, 3.2, 3.3, 4.0, 4.1, 4.2, 4.3, 4.4., and 4.5.
OpenGL uses a deprecation model for removing outdated parts of its API which results in compatibility (with deprecated API) and core (without deprecated API) usage that is manifested in the targeted OpenGL context.
On top of that, new API concepts are suggested as extensions (often vendor specific) that might be integrated into future versions.
All this results in many possible specific manifestations of the OpenGL API you can use in your program.

One tough task is to adhere to one agreed set of functions in your own OpenGL program (e.g., OpenGL 3.2 Core if you want to develop for every Windows, macOS, and Linux released in the last 4 years).
glbinding facilitates this by providing per-feature headers by means of well-defined/generated subsets of the OpenGL API.

All-Features OpenGL Headers

If you do not use per-feature headers the OpenGL program can look like this:

Single-Feature OpenGL Headers

When developing your code on Windows with latest drivers installed, the code above is likely to compile and run.
But if you want to port it to systems with less mature driver support (e.g., macOS or Linux using open source drivers), you may wonder if glDrawElementsInstanced is available.
In this case, just switch to per-feature headers of glbinding and choose the OpenGL 3.2 Core headers (as you know that at least this version is available on all target platforms):

Multi-Context Support

glbinding has built-in support for multiple contexts. The only requirement is, that the currently active context has to be specified. This feature mixes well with multi-threaded applications, but keep in mind that concurrent use of one context often results in non-meaningful communication with the OpenGL driver.

In order to use multiple contexts, use your favorite context creation library (e.g., glut, SDL, egl, glfw, Qt) to request the required contexts.
The functions to make a context current should be provided by these libraries and is not part of glbinding (except that you can get the current context handle).
When using multiple contexts, glbinding has to be initialized for each context (when current).

Since each context can correspond to a different feature set of OpenGL and the drivers are free to assign their function pointers, glbinding cannot assume any equalities of requested function pointers.
Thus, contexts switches have to be communicated to glbinding explicitly in order to have correctly dispatched function pointers:

// use the current active context
glbinding::useCurrentContext();
// use another context, identified by platform-specific handle
glbinding::useContext(ContextHandle context);

Multi-Threading Support

Concurrent use of glbinding is mainly intended for usage over multiple contexts in different threads (multiple threads operating on a single OpenGL context requires locking, which glbinding will not provide).
For it, glbinding supports multiple active contexts, one per thread.
This necessitates that glbinding gets informed in each thread which context is currently active (see multi-context).
Note: multi-threaded communication with OpenGL will most likely result in a meaningless sequence of OpenGL calls.
To avoid this, semantic groups of OpenGL calls should be treated as critical sections.

Multiple OpenGL Contexts in Multiple Threads

The combination of multiple OpenGL contexts and multiple threads for OpenGL usage is supported by glbinding in general.
You must tell glbinding which OpenGL context is used in which thread by calling the initialize method once the context is used first (glbinding::initialize) and if you want to switch the current context for one thread, you have to update the current context, too (glbinding::useContext).
However, we discourage the use of one context in multiple threads.

Function Callbacks

To support orthogonal features of the OpenGL API, glbinding allows attaching a number of callbacks to several concepts of the OpenGL API (e.g. a function).
Such orthogonal features include runtime error checking (i.e., glGetError after each function call), logging, and caching of driver information.

glbinding supports different types of callbacks that can be registered.
The main types are

global and local (per-function) before callbacks, that are called before the OpenGL function call,

global and local (per-function) after callbacks, that are called after the OpenGL function call,

unresolved callbacks, that are called each time an unresolved OpenGL function should be called (instead of a segmentation fault),

context switch callbacks, that are called if the internal current OpenGL context of glbinding is changed.

The before callbacks are useful , e.g., for tracing or application-specific parameter checking.
The available information in this callback is the wrapped OpenGL function (including its name and bound function address) and all parameters.
The after callbacks are useful, e.g., for tracing, logging, or the obligatory error check (glGetError.
Available information is extended by the return value.
The unresolved callback provides information about the (unresolved) wrapped OpenGL function object.

Alternative Signatures

The OpenGL API is designed without function overloading using only simple parameter types.
This results in explicit parameter encoding in function names for conceptually overloaded functions (e.g., glTexParameteri and glTexParameterf).
Another design decision for the OpenGL API is the high similarity of the integer, boolean, enum, and bitfield data types.
This means, that for overloaded functions, there is no separate function for GLboolean, GLenum, and GLbitfield types.
Using type-save functions of glbinding, some typically compiling code constructs are now deliberately broken.
For most of those cases, we provide alternative overloaded function signatures.
Additionally, we also fix signatures that are semantically broken in the OpenGL API specification, i.e., when base types (C types) are similar such as in the case of enums and integers.

Alternative function signatures are enabled by default, so the following example works out-of-the-box:

Meta Information

Besides an actual OpenGL binding, glbinding also supports queries for both compile time and runtime information about the gl.xml and your OpenGL driver within the glbinding-aux library. This library comes with own includes and needs to be linked seperately.
Typical use cases are querying the available OpenGL extensions or the associated extensions to an OpenGL feature and their functions and enums.

The following example prints out a list of all available OpenGL versions/features:

Professional Support

CG Internals offers computer graphics R&D as well as reliable technology and innovative concepts to support your computer graphics visions.
We provide trainings and can help you integrate and customize cpplocate in your next project.