1*706d0b42SXin Li 2*706d0b42SXin Li 3*706d0b42SXin Li 4*706d0b42SXin Li 5*706d0b42SXin Li[](https://opensource.org/licenses/MIT) 6*706d0b42SXin Li 7*706d0b42SXin LiEpoxy is a library for handling OpenGL function pointer management for 8*706d0b42SXin Liyou. 9*706d0b42SXin Li 10*706d0b42SXin LiIt hides the complexity of `dlopen()`, `dlsym()`, `glXGetProcAddress()`, 11*706d0b42SXin Li`eglGetProcAddress()`, etc. from the app developer, with very little 12*706d0b42SXin Liknowledge needed on their part. They get to read GL specs and write 13*706d0b42SXin Licode using undecorated function names like `glCompileShader()`. 14*706d0b42SXin Li 15*706d0b42SXin LiDon't forget to check for your extensions or versions being present 16*706d0b42SXin Libefore you use them, just like before! We'll tell you what you forgot 17*706d0b42SXin Lito check for instead of just segfaulting, though. 18*706d0b42SXin Li 19*706d0b42SXin LiFeatures 20*706d0b42SXin Li-------- 21*706d0b42SXin Li 22*706d0b42SXin Li * Automatically initializes as new GL functions are used. 23*706d0b42SXin Li * GL 4.6 core and compatibility context support. 24*706d0b42SXin Li * GLES 1/2/3 context support. 25*706d0b42SXin Li * Knows about function aliases so (e.g.) `glBufferData()` can be 26*706d0b42SXin Li used with `GL_ARB_vertex_buffer_object` implementations, along 27*706d0b42SXin Li with GL 1.5+ implementations. 28*706d0b42SXin Li * EGL, GLX, and WGL support. 29*706d0b42SXin Li * Can be mixed with non-epoxy GL usage. 30*706d0b42SXin Li 31*706d0b42SXin LiBuilding 32*706d0b42SXin Li-------- 33*706d0b42SXin Li 34*706d0b42SXin Li```sh 35*706d0b42SXin Limkdir _build && cd _build 36*706d0b42SXin Limeson 37*706d0b42SXin Lininja 38*706d0b42SXin Lisudo ninja install 39*706d0b42SXin Li``` 40*706d0b42SXin Li 41*706d0b42SXin LiDependencies for Debian: 42*706d0b42SXin Li 43*706d0b42SXin Li * meson 44*706d0b42SXin Li * libegl1-mesa-dev 45*706d0b42SXin Li 46*706d0b42SXin LiDependencies for macOS (using MacPorts): 47*706d0b42SXin Li 48*706d0b42SXin Li * pkgconfig 49*706d0b42SXin Li * meson 50*706d0b42SXin Li 51*706d0b42SXin LiThe test suite has additional dependencies depending on the platform. 52*706d0b42SXin Li(X11, EGL, a running X Server). 53*706d0b42SXin Li 54*706d0b42SXin LiSwitching your code to using epoxy 55*706d0b42SXin Li---------------------------------- 56*706d0b42SXin Li 57*706d0b42SXin LiIt should be as easy as replacing: 58*706d0b42SXin Li 59*706d0b42SXin Li```cpp 60*706d0b42SXin Li#include <GL/gl.h> 61*706d0b42SXin Li#include <GL/glx.h> 62*706d0b42SXin Li#include <GL/glext.h> 63*706d0b42SXin Li``` 64*706d0b42SXin Li 65*706d0b42SXin Liwith: 66*706d0b42SXin Li 67*706d0b42SXin Li```cpp 68*706d0b42SXin Li#include <epoxy/gl.h> 69*706d0b42SXin Li#include <epoxy/glx.h> 70*706d0b42SXin Li``` 71*706d0b42SXin Li 72*706d0b42SXin LiAs long as epoxy's headers appear first, you should be ready to go. 73*706d0b42SXin LiAdditionally, some new helpers become available, so you don't have to 74*706d0b42SXin Liwrite them: 75*706d0b42SXin Li 76*706d0b42SXin Li`int epoxy_gl_version()` returns the GL version: 77*706d0b42SXin Li 78*706d0b42SXin Li * 12 for GL 1.2 79*706d0b42SXin Li * 20 for GL 2.0 80*706d0b42SXin Li * 44 for GL 4.4 81*706d0b42SXin Li 82*706d0b42SXin Li`bool epoxy_has_gl_extension()` returns whether a GL extension is 83*706d0b42SXin Liavailable (`GL_ARB_texture_buffer_object`, for example). 84*706d0b42SXin Li 85*706d0b42SXin LiNote that this is not terribly fast, so keep it out of your hot paths, 86*706d0b42SXin Liok? 87*706d0b42SXin Li 88*706d0b42SXin LiWhy not use libGLEW? 89*706d0b42SXin Li-------------------- 90*706d0b42SXin Li 91*706d0b42SXin LiGLEW has several issues: 92*706d0b42SXin Li 93*706d0b42SXin Li * Doesn't know about aliases of functions (There are 5 providers of 94*706d0b42SXin Li `glPointParameterfv()`, for example, and you don't want to have to 95*706d0b42SXin Li choose which one to call when they're all the same). 96*706d0b42SXin Li * Doesn't support OpenGL ES. 97*706d0b42SXin Li * Has a hard-to-maintain parser of extension specification text 98*706d0b42SXin Li instead of using the old .spec file or the new .xml. 99*706d0b42SXin Li * Has significant startup time overhead when `glewInit()` 100*706d0b42SXin Li autodetects the world. 101*706d0b42SXin Li * User-visible multithreading support choice for win32. 102*706d0b42SXin Li 103*706d0b42SXin LiThe motivation for this project came out of previous use of libGLEW in 104*706d0b42SXin Li[piglit](http://piglit.freedesktop.org/). Other GL dispatch code 105*706d0b42SXin Ligeneration projects had similar failures. Ideally, piglit wants to be 106*706d0b42SXin Liable to build a single binary for a test that can run on whatever 107*706d0b42SXin Licontext or window system it chooses, not based on link time choices. 108*706d0b42SXin Li 109*706d0b42SXin LiWe had to solve some of GLEW's problems for piglit and solving them 110*706d0b42SXin Limeant replacing every single piece of GLEW, so we built 111*706d0b42SXin Lipiglit-dispatch from scratch. And since we wanted to reuse it in 112*706d0b42SXin Liother GL-related projects, this is the result. 113*706d0b42SXin Li 114*706d0b42SXin LiKnown issues when running on Windows 115*706d0b42SXin Li------------------------------------ 116*706d0b42SXin Li 117*706d0b42SXin LiThe automatic per-context symbol resolution for win32 requires that 118*706d0b42SXin Liepoxy knows when `wglMakeCurrent()` is called, because `wglGetProcAddress()` 119*706d0b42SXin Lireturns values depend on the context's device and pixel format. If 120*706d0b42SXin Li`wglMakeCurrent()` is called from outside of epoxy (in a way that might 121*706d0b42SXin Lichange the device or pixel format), then epoxy needs to be notified of 122*706d0b42SXin Lithe change using the `epoxy_handle_external_wglMakeCurrent()` function. 123*706d0b42SXin Li 124*706d0b42SXin LiThe win32 `wglMakeCurrent()` variants are slower than they should be, 125*706d0b42SXin Libecause they should be caching the resolved dispatch tables instead of 126*706d0b42SXin Liresetting an entire thread-local dispatch table every time. 127