| commit | 4b7b5422dbb705ec0dab00cc18a8e915f8b334c0 | [log] [tgz] |
|---|---|---|
| author | Emmanuele Bassi <ebassi@gnome.org> | Thu Feb 09 13:51:30 2017 +0000 |
| committer | Emmanuele Bassi <ebassi@gnome.org> | Thu Feb 09 14:20:51 2017 +0000 |
| tree | 8674297b421e2dee813b76f6ae96d75618a226ef | |
| parent | 9b56140962ee6358184fb7c4ff2d5e3fac7dd7a9 [diff] |
Update the TravisCI environment to use Docker
The Travis environment is terribly outdated, and they are not really
subtly pushing people to use Docker to set up their own containerised CI
environments instead of pulling from Ubuntu 12.04 or 14.04.
Let's try using this approach:
- create a Docker image that pulls from Debian Stretch
- set up a build and test environment
- push the image to the Docker Hub
- create a derived Docker image that copies the Epoxy repo
when running under Travis
- run the build and test script inside the derived image
This is similar to what Meson does for its CI.
Epoxy is a library for handling OpenGL function pointer management for you.
It hides the complexity of dlopen(), dlsym(), glXGetProcAddress(), eglGetProcAddress(), etc. from the app developer, with very little knowledge needed on their part. They get to read GL specs and write code using undecorated function names like glCompileShader().
Don't forget to check for your extensions or versions being present before you use them, just like before! We'll tell you what you forgot to check for instead of just segfaulting, though.
glBufferData() can be used with GL_ARB_vertex_buffer_object implementations, along with GL 1.5+ implementations.mkdir _build && cd _build meson ninja sudo ninja install
Dependencies for Debian:
Dependencies for macOS (using MacPorts):
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 to write them:
int epoxy_gl_version() returns the GL version:
bool epoxy_has_gl_extension() returns whether a GL extension is available (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:
glPointParameterfv(), for example, and you don't want to have to choose which one to call when they're all the same).glewInit() autodetects the world.The motivation for this project came out of previous use of libGLEW in piglit. Other GL dispatch code generation projects had similar failures. Ideally, piglit wants to be able to build a single binary for a test that can run on whatever context or window system it chooses, not based on link time choices.
We had to solve some of GLEW's problems for piglit and solving them meant replacing every single piece of GLEW, so we built piglit-dispatch from scratch. And since we wanted to reuse it in other GL-related projects, this is the result.
The automatic per-context symbol resolution for win32 requires that epoxy knows when wglMakeCurrent() is called, because wglGetProcAddress() returns values depend on the context's device and pixel format. If wglMakeCurrent() is called from outside of epoxy (in a way that might change the device or pixel format), then epoxy needs to be notified of the change using the epoxy_handle_external_wglMakeCurrent() function.
The win32 wglMakeCurrent() variants are slower than they should be, because they should be caching the resolved dispatch tables instead of resetting an entire thread-local dispatch table every time.