On Fri Mar 8 18:22:26 2024 +0000, Rémi Bernon wrote:
Ah yeah I forgot about that before but isn't something that's supposed to be called on every thread that is going to issue GL calls? Shouldn't we do that in wglMakeCurrent?
`eglBindAPI` affects the result of certain EGL calls, and only indirectly affects the client APIs (GL etc) themselves (through the current context).
The EGL specifications (>= 1.4) say in section 3.7:
EGL_OPENGL_API and EGL_OPENGL_ES_API are interchangeable for all purposes except eglCreateContext.
This is elaborated further in the documentation of various affected EGL functions listed in the spec. The ones relevant to us at the moment are:
* `eglCreateContext`: we call eglBindAPI before this one, so we are covered, i.e., we always create OpenGL contexts * `eglMakeCurrent`: The spec says: > For purposes of eglMakeCurrent, the client API type of all OpenGL ES and OpenGL contexts is considered the same. In other words, if any OpenGL ES context is currently bound and context is an OpenGL context, or if any OpenGL context is currently bound and context is an OpenGL ES context, the currently bound context will be made no longer current and context will be made current.
Since the default API is OpenGL ES, it's fine to make an OpenGL context current even if the thread hasn't explicitly called `eglBindAPI(EGL_OPENGL_API)`. * `eglSwapInterval`: This works on the draw surface of the current context, so the considerations of `eglMakeCurrent` apply (i.e., there is a single current context for both OpenGL and OpenGL ES).