We shouldn't assume the GLchar is a valid typedef with all GL headers
when declaring all the symbols in cogl-ext-functions.h to lookup. GLchar
may not be avilable with gles1 for example so we were seeing build
failures. The patch simply replaces occurrences of GLchar with char.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
in cogl-ext-functions.h we had one multitexture feature that checked for
the ARB_multitexture extension and if found it then expected to find
glActiveTexture and glClientActiveTexture. The problem is that the
multitexture extension is part of the core GLES 1 and 2 APIs except that
for GLES2 there is no glClientActiveTexture function. By trying to
handle it as one feature that meant that Cogl would fail to check the
multitexture extension which is a hard requirement for Cogl.
The reason this went unnoticed is because Cogl can indirectly end up
linked to an OpenGL library via cairo and so we were finding a
glClientActiveTexture symbol there. This highlights that we should
probably stop using g_module_open (NULL) when checking features and
instead we should use the module we opened in cogl-renderer.c.
The GL or GLES library is now dynamically loaded by the CoglRenderer
so that it can choose between GL, GLES1 and GLES2 at runtime. The
library is loaded by the renderer because it needs to be done before
calling eglInitialize. There is a new environment variable called
COGL_DRIVER to choose between gl, gles1 or gles2.
The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have
been changed so that they don't assume the ifdefs are mutually
exclusive. They haven't been removed entirely so that it's possible to
compile the GLES backends without the the enums from the GL headers.
When using GLX the winsys additionally dynamically loads libGL because
that also contains the GLX API. It can't be linked in directly because
that would probably conflict with the GLES API if the EGL is
selected. When compiling with EGL support the library links directly
to libEGL because it doesn't contain any GL API so it shouldn't have
any conflicts.
When building for WGL or OSX Cogl still directly links against the GL
API so there is a #define in config.h so that Cogl won't try to dlopen
the library.
Cogl-pango previously had a #ifdef to detect when the GL backend is
used so that it can sneakily pass GL_QUADS to
cogl_vertex_buffer_draw. This is now changed so that it queries the
CoglContext for the backend. However to get this to work Cogl now
needs to export the _cogl_context_get_default symbol and cogl-pango
needs some extra -I flags to so that it can include
cogl-context-private.h
cogl-ext-functions.h now contains definitions for all of the core GL
and GLES functions that we would normally link to directly. All of the
code has changed to access them through the cogl context pointer. The
GE macro now takes an extra parameter to specify the context because
the macro itself needs to make GL calls but various points in the Cogl
source use different names for the context variable.
Instead of storing all of the feature function pointers in the driver
specific data of the CoglContext they are now all stored directly in
CoglContext. There is a single header containing the description of
the functions which gets included by cogl-context.h. There is a single
function in cogl-feature-private.c to check for all of these
functions.
The name of the function pointer variables have been changed from
ctx->drv.pf_glWhatever to just ctx->glWhatever.
The feature flags that get set when an extension is available are now
separated from the table of extensions. This is necessary because
different extensions can mean different things on GLES and GL. For
example, having access to glMapBuffer implies read and write support
on GL but only write support on GLES. The flags are instead set in the
driver specific init function by checking whether the function
pointers were successfully resolved.
_cogl_feature_check has been changed to assume the feature is
supported if any of the listed extensions are available instead of
requiring all of them. This makes it more convenient to specify
alternate names for the extension. Nothing else had previously listed
more than one name for an extension so this shouldn't cause any
problems.
