xref: /aosp_15_r20/external/libepoxy/README.md (revision 706d0b42ae4182339789e08d473a0b312ecdc60f)
1*706d0b42SXin Li![Ubuntu](https://github.com/anholt/libepoxy/workflows/Ubuntu/badge.svg)
2*706d0b42SXin Li![macOS](https://github.com/anholt/libepoxy/workflows/macOS/badge.svg)
3*706d0b42SXin Li![MSVC Build](https://github.com/anholt/libepoxy/workflows/MSVC%20Build/badge.svg)
4*706d0b42SXin Li![MSYS2 Build](https://github.com/anholt/libepoxy/workflows/MSYS2%20Build/badge.svg)
5*706d0b42SXin Li[![License: MIT](https://img.shields.io/badge/license-MIT-brightgreen.svg)](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