According to the EGL spec, eglGetProcAddress should only be used to
retrieve extension functions. It also says that returning non-NULL
does not mean the extension is available so you could interpret this
as saying that the function is allowed to return garbage for core
functions. This seems to happen at least for the Android
implementation of EGL.
To workaround this the winsys's are now passed down a flag to say
whether the function is from the core API. This information is already
in the gl-prototypes headers as the minimum core GL version and as a
pair of flags to specify whether it is available in core GLES1 and
GLES2. If the function is in core the EGL winsys will now avoid using
eglGetProcAddress and always fallback to querying the library directly
with the GModule API.
The GLX winsys is left alone because glXGetProcAddress apparently
supports querying core API and extension functions.
The WGL winsys could ideally be changed because wglGetProcAddress
should also only be used for extension functions but the situation is
slightly different because WGL considers anything from GL > 1.1 to be
an extension so it would need a bit more information to determine
whether to query the function directly from the library.
The SDL winsys is also left alone because it's not as easy to portably
determine which GL library SDL has chosen to load in order to resolve
the symbols directly.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 72089730ad06ccdd38a344279a893965ae68cec1)
Since we aren't able to break API on the 1.12 branch
cogl_get_proc_address is still supported but isn't easily able to
determine whether the given name corresponds to a core symbol or
not. For now we just assume the symbol being queried isn't part
of the core GL api and update the documentation accordingly.
This adds an alternate version of the SDL winsys using the SDL 2 API.
The two versions are mutually exclusive and share the same
CoglWinsysID. Version 2 of SDL fits a little bit better with Cogl
because it supports multiple windows and the video subsystem can be
initialised entirely independently of the rest of the subsystems.
The SDL2 winsys creates an invisible dummy window in order to bind the
GL context after creating the Cogl display. This is similar to how the
X11 winsys's work.
SDL2 seems to support compiling with support for both GL and GLES.
However there doesn't seem to be a way to select between the two
backends outside of SDL. In fact if you do compile them both in it
seems to break down because it will always try to use the window
system functions from the GLES backend because those are filled in
second in the vtable. However when creating the window it will always
prefer to use the GL function to choose a visual. This function gets
confused because the GL backend has not been initialised at that
point. The Cogl backend therefore just leaves it up to SDL to pick a
sensible backend. It will then verify that it picked a GL library
which matches the Cogl driver by checking the string from
glGetString(GL_VERSION).
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 6cb5ab41355e7bfe28f367cf4afa39a7afcfeec2)
