The check to verify whether we've got the right GL context was
checking that the GL version was less than 3 whenever the non-GL3
driver is used. However it looks like the driver is free to return a
GL3 context that is compatible with GL2 if GL2 is requested so this
was breaking the GL2 driver.
This also adds the necessary SDL attributes to request a forward
compatible core context like the GLX and EGL winsys's do. I haven't
actually tested this because it looks like SDL will only create a GL
context with GLX and I haven't got a recent enough X server to handle
the glXCreateContextAttribs request.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit d46acafa3ea7ba2e6c4ac7a45f00a132df1b2872)
The SDL2 winsys was using _cogl_set_error without including its header
so it was giving an annoying warning. This patch also fixes some
indentation issues.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 9c8433087b7573f7606dfae2bae3045803ead115)
This adds a new CoglDriver for GL 3 called COGL_DRIVER_GL3. When
requested, the GLX, EGL and SDL2 winsyss will set the necessary
attributes to request a forward-compatible core profile 3.1 context.
That means it will have no deprecated features.
To simplify the explosion of checks for specific combinations of
context->driver, many of these conditionals have now been replaced
with private feature flags that are checked instead. The GL and GLES
drivers now initialise these private feature flags depending on which
driver is used.
The fixed function backends now explicitly check whether the fixed
function private feature is available which means the GL3 driver will
fall back to always using the GLSL progend. Since Rob's latest patches
the GLSL progend no longer uses any fixed function API anyway so it
should just work.
The driver is currently lower priority than COGL_DRIVER_GL so it will
not be used unless it is specificly requested. We may want to change
this priority at some point because apparently Mesa can make some
memory savings if a core profile context is used.
In GL 3, getting the combined extensions string with glGetString is
deprecated so this patch changes it to use glGetStringi to build up an
array of extensions instead. _cogl_context_get_gl_extensions now
returns this array instead of trying to return a const string. The
caller is expected to free the array.
Some issues with this patch:
• GL 3 does not support GL_ALPHA format textures. We should probably
make this a feature flag or something. Cogl uses this to render text
which currently just throws a GL error and breaks so it's pretty
important to do something about this before considering the GL3
driver to be stable.
• GL 3 doesn't support client side vertex buffers. This probably
doesn't matter because CoglBuffer won't normally use malloc'd
buffers if VBOs are available, but it might but worth making
malloc'd buffers a private feature and forcing it not to use them.
• GL 3 doesn't support the default vertex array object. This patch
just makes it create and bind a single non-default vertex array
object which gets used just like the normal default object. Ideally
it would be good to use vertex array objects properly and attach
them to a CoglPrimitive to cache the state.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 66c9db993595b3a22e63f4c201ea468bc9b88cb6)
Although we use GLib internally in Cogl we would rather not leak GLib
api through Cogl's own api, except through explicitly namespaced
cogl_glib_ / cogl_gtype_ feature apis.
One of the benefits we see to not leaking GLib through Cogl's public API
is that documentation for Cogl won't need to first introduce the Glib
API to newcomers, thus hopefully lowering the barrier to learning Cogl.
This patch provides a Cogl specific typedef for reporting runtime errors
which by no coincidence matches the typedef for GError exactly. If Cogl
is built with --enable-glib (default) then developers can even safely
assume that a CoglError is a GError under the hood.
This patch also enforces a consistent policy for when NULL is passed as
an error argument and an error is thrown. In this case we log the error
and abort the application, instead of silently ignoring it. In common
cases where nothing has been implemented to handle a particular error
and/or where applications are just printing the error and aborting
themselves then this saves some typing. This also seems more consistent
with language based exceptions which usually cause a program to abort if
they are not explicitly caught (which passing a non-NULL error signifies
in this case)
Since this policy for NULL error pointers is stricter than the standard
GError convention, there is a clear note in the documentation to warn
developers that are used to using the GError api.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit b068d5ea09ab32c37e8c965fc8582c85d1b2db46)
Note: Since we can't change the Cogl 1.x api the patch was changed to
not rename _error_quark() functions to be _error_domain() functions and
although it's a bit ugly, instead of providing our own CoglError type
that's compatible with GError we simply #define CoglError to GError
unless Cogl is built with glib disabled.
Note: this patch does technically introduce an API break since it drops
the cogl_error_get_type() symbol generated by glib-mkenum (Since the
CoglError enum was replaced by a CoglSystemError enum) but for now we
are assuming that this will not affect anyone currently using the Cogl
API. If this does turn out to be a problem in practice then we would be
able to fix this my manually copying an implementation of
cogl_error_get_type() generated by glib-mkenum into a compatibility
source file and we could also define the original COGL_ERROR_ enums for
compatibility too.
Note: another minor concern with cherry-picking this patch to the 1.14
branch is that an api scanner would be lead to believe that some APIs
have changed, and for example the gobject-introspection parser which
understands the semantics of GError will not understand the semantics of
CoglError. We expect most people that have tried to use
gobject-introspection with Cogl already understand though that it is not
well suited to generating bindings of the Cogl api anyway and we aren't
aware or anyone depending on such bindings for apis involving GErrors.
(GnomeShell only makes very-very minimal use of Cogl via the gjs
bindings for the cogl_rectangle and cogl_color apis.)
The main reason we have cherry-picked this patch to the 1.14 branch
even given the above concerns is that without it it would become very
awkward for us to cherry-pick other beneficial patches from master.
The ‘length’ for the swap chain is initially -1 which is supposed to
mean ‘no preference’. However, both of the SDL winsys's were
explicitly setting the SDL_GL_DOUBLEBUFFER attribute to zero in that
case which would try to disable double buffering.
On OS X, the equivalent to eglSwapBuffers (ie, [NSOpenGLContext
flushBuffer]) does nothing for a single buffer context. The
cogl-sdl-hello example does not specify the swap chain length so
presumably it would end up with a single buffer config. When
cogl_onscreen_swap_buffers is called it therefore does nothing and
nothing is painted.
I guess to make single-buffered contexts actually useful we should
expose some public equivalent to glFlush so that you can ensure the
rendering commands will actually hit the buffer. Alternatively we
could document that cogl_onscreen_swap_buffers performs this task on
single-buffered configs and then we could make the SDL winsys
explicitly call glFlush in that case.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 71e57f99002d5dee79bbd44b3bc57712b99acb55)
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)
