Repository files navigation

Epoxy is a library for handling OpenGL function pointer management foryou.

It hides the complexity ofdlopen(),dlsym(),glXGetProcAddress(),eglGetProcAddress(), etc. from the app developer, with very littleknowledge needed on their part. They get to read GL specs and writecode using undecorated function names likeglCompileShader().

Don't forget to check for your extensions or versions being presentbefore you use them, just like before! We'll tell you what you forgotto check for instead of just segfaulting, though.

• Automatically initializes as new GL functions are used.
• GL 4.6 core and compatibility context support.
• GLES 1/2/3 context support.
• Knows about function aliases so (e.g.)glBufferData() can beused withGL_ARB_vertex_buffer_object implementations, alongwith GL 1.5+ implementations.
• EGL, GLX, and WGL support.
• Can be mixed with non-epoxy GL usage.

mkdir _build&&cd _buildmesonninjasudo ninja install

Dependencies for Debian:

• meson
• libegl1-mesa-dev

Dependencies for macOS (using MacPorts):

• pkgconfig
• meson

The test suite has additional dependencies depending on the platform.(X11, EGL, a running X Server).

It should be as easy as replacing:

#include<GL/gl.h>#include<GL/glx.h>#include<GL/glext.h>

with:

#include<epoxy/gl.h>#include<epoxy/glx.h>

As long as epoxy's headers appear first, you should be ready to go.Additionally, some new helpers become available, so you don't have towrite them:

int epoxy_gl_version() returns the GL version:

• 12 for GL 1.2
• 20 for GL 2.0
• 44 for GL 4.4

bool epoxy_has_gl_extension() returns whether a GL extension isavailable (GL_ARB_texture_buffer_object, for example).

Note that this is not terribly fast, so keep it out of your hot paths,ok?

GLEW has several issues:

• Doesn't know about aliases of functions (There are 5 providers ofglPointParameterfv(), for example, and you don't want to have tochoose which one to call when they're all the same).
• Doesn't support OpenGL ES.
• Has a hard-to-maintain parser of extension specification textinstead of using the old .spec file or the new .xml.
• Has significant startup time overhead whenglewInit()autodetects the world.
• User-visible multithreading support choice for win32.

The motivation for this project came out of previous use of libGLEW inpiglit. Other GL dispatch codegeneration projects had similar failures. Ideally, piglit wants to beable to build a single binary for a test that can run on whatevercontext or window system it chooses, not based on link time choices.

We had to solve some of GLEW's problems for piglit and solving themmeant replacing every single piece of GLEW, so we builtpiglit-dispatch from scratch. And since we wanted to reuse it inother GL-related projects, this is the result.

The automatic per-context symbol resolution for win32 requires thatepoxy knows whenwglMakeCurrent() is called, becausewglGetProcAddress()returns values depend on the context's device and pixel format. IfwglMakeCurrent() is called from outside of epoxy (in a way that mightchange the device or pixel format), then epoxy needs to be notified ofthe change using theepoxy_handle_external_wglMakeCurrent() function.

The win32wglMakeCurrent() variants are slower than they should be,because they should be caching the resolved dispatch tables instead ofresetting an entire thread-local dispatch table every time.