Commits on Source (3)
-
Use the correct OpenGL flavour (GLES or OpenGL) at runtime by providing both capabilities, fixing the usage of OpenGL filters through GLES2 on Linux where both are supported. The filter only has a single implementation, but will probe both OpenGL and OpenGL ES2 by default. It can be restricted to a specific flavour by enforcing a gl module to `any` or any specific implementation. Eg. --video-filter=opengl{filter=mock,gles=any} --video-filter=opengl{filter=mock,gl=any} --video-filter=opengl{filter=mock,gl=any,gles=foo} OpenGL is favoured when probing since it provides much more functionality and performance optimization opportunities that its embedded counterpart. However, when USE_OPENGL_ES2 is defined, it means that OpenGL headers were not available. In this case, it's highly likely that OpenGL is **not** available at all and we only probe OpenGL ES instead. There are guenuine reasons why it could fail on OpenGL but not on OpenGL ES, like the presence of an extension like the support for GL_OES_EGL_image_external or the non-support of anything else but OpenGL ES with a given version.
dac685b7 -
Provide both the OpenGL offscreen implementation and the GLES2 offscreen implementation from the same module, since it's the same code. There is no need to differentiate the name between any of the two modules, just like we don't need for EGL, because they have distinct capabilities and are referred by separate objects anyway (--opengl-gl versus --opengl-gles).
dd10f6ba -
We can support GL ES3 even if the capability name doesn't reflect that, since it's mostly a "at least GLES 2". By doing so, we can simplify the checks on the EGL client version.
4d100f60