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.
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.
The coding style has for a long time said to avoid using redundant glib
data types such as gint or gchar etc because we feel that they make the
code look unnecessarily foreign to developers coming from outside of the
Gnome developer community.
Note: When we tried to find the historical rationale for the types we
just found that they were apparently only added for consistent syntax
highlighting which didn't seem that compelling.
Up until now we have been continuing to use some of the platform
specific type such as gint{8,16,32,64} and gsize but this patch switches
us over to using the standard c99 equivalents instead so we can further
ensure that our code looks familiar to the widest range of C developers
who might potentially contribute to Cogl.
So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this
switches all Cogl code to instead use the int{8,16,32,64}_t and
uint{8,16,32,64}_t c99 types instead.
Instead of gsize we now use size_t
For now we are not going to use the c99 _Bool type and instead we have
introduced a new CoglBool type to use instead of gboolean.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
This option to GCC makes it give a warning whenever a global function
is defined without a declaration. This should catch cases were we've
defined a function but forgot to put it in a header. In that case it
is either only used within one file so we should make it static or we
should declare it in a header.
The following changes where made to fix problems:
• Some functions were made static
• cogl-path.h (the one containing the 1.0 API) was split into two
files, one defining the functions and one defining the enums so that
cogl-path.c can include the enum and function declarations from the
2.0 API as well as the function declarations from the 1.0 API.
• cogl2-clip-state has been removed. This only had one experimental
function called cogl_clip_push_from_path but as this is unstable we
might as well remove it favour of the equivalent cogl_framebuffer_*
API.
• The GLX, SDL and WGL winsys's now have a private header to define
their get_vtable function instead of directly declaring in the C
file where it is called.
• All places that were calling COGL_OBJECT_DEFINE need to have the
cogl_is_whatever function declared so these have been added either
as a public function or in a private header.
• Some files that were not including the header containing their
function declarations have been fixed to do so.
• Any unused error quark functions have been removed. If we later want
them we should add them back one by one and add a declaration for
them in a header.
• _cogl_is_framebuffer has been renamed to cogl_is_framebuffer and
made a public function with a declaration in cogl-framebuffer.h
• Similarly for CoglOnscreen.
• cogl_vdraw_indexed_attributes is called
cogl_framebuffer_vdraw_indexed_attributes in the header. The
definition has been changed to match the header.
• cogl_index_buffer_allocate has been removed. This had no declaration
and I'm not sure what it's supposed to do.
• CoglJournal has been changed to use the internal CoglObject macro so
that it won't define an exported cogl_is_journal symbol.
• The _cogl_blah_pointer_from_handle functions have been removed.
CoglHandle isn't used much anymore anyway and in the few places
where it is used I think it's safe to just use the implicit cast
from void* to the right type.
• The test-utils.h header for the conformance tests explicitly
disables the -Wmissing-declaration option using a pragma because all
of the tests declare their main function without a header. Any
mistakes relating to missing declarations aren't really important
for the tests.
• cogl_quaternion_init_from_quaternion and init_from_matrix have been
given declarations in cogl-quaternion.h
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Deal with c99ism... I know it's not pretty, but it is the way
to go with non-c99 compilers. That's life...
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Previously, _cogl_get_proc_address had a fallback to resolve the
symbol using g_module_open(NULL) to get the symbol from anywhere in
the address space. The EGL backend ends up using this on some drivers
because eglGetProcAddress isn't meant to return a pointer for core
functions. This causes problems if something in the process is linking
against a different GL library, for example Cairo may be linking
against libGL itself. In this case it may end up resolving symbols
from the GL library even if GLES is being used.
This patch removes the fallback. The EGL version now has its own
fallback instead which passes the existing libgl_module from the
renderer to g_module_symbol so that it should only get symbols from
that library or its dependency chain. The GLX and WGL winsys only call
glXGetProcAddress and wglGetProcAddress. The stub winsys does however
continue using the global symbol lookup.
The internal _cogl_get_proc_address function has been renamed to
_cogl_renderer_get_proc_address because it needs a connected renderer
to work so it could be considered to be a renderer method. The pointer
to the renderer is passed down to the winsys backends so that it can
use the data attached to the renderer to get the module pointers.
https://bugzilla.gnome.org/show_bug.cgi?id=655412
Reviewed-by: Robert Bragg <robert@linux.intel.com>
The _cogl_context_check_gl_version function is meant to be called once
Cogl has a GL context so that it can check whether the context found
is supported by Cogl. However, only the stub winsys was calling this
and it was doing it before Cogl had a chance to retrieve the function
pointer for glString so it would just crash. This patch combines the
two functions into one so that _cogl_context_update_features returns a
gboolean and a GError. Then it can just check the context itself.
https://bugzilla.gnome.org/show_bug.cgi?id=654440
Reviewed-by: Robert Bragg <robert@linux.intel.com>
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
This adds API to let you override the choice of Cogl's winsys backend.
Previously it was only possible to override the winsys using the
COGL_RENDERER environment variable, but it's useful for something like
Clutter to be able to control the winsys via API without needing
environment variable tricks. This also adds API to query back the
winsys chosen by Cogl, in case you don't set an explicit override.
Signed-off-by: Neil Roberts <neil@linux.intel.com>
Instead of the stub winsys being a special case set of #ifdef'd code
used when COGL_HAS_FULL_WINSYS wasn't defined, the stub winsys now
implements a CoglWinsysVtable like all other winsys backends (it's just
that everything is a NOP). This way we can get rid of the
COGL_HAS_FULL_WINSYS define and also the stub winsys can be runtime
selected whereas before it was incompatible with all other winsys
backends.
Until Cogl gains native win32/OSX support this remove the osx and win32
winsys files and instead we'll just rely on the stub-winsys.c to handle
these platforms. Since the only thing the platform specific files were
providing anyway was a get_proc_address function; it was trivial to
simply update the clutter backend code to handle this directly for now.
Commit b061f737 moved _cogl_winsys_has_feature to the common winsys
code so there's no need to define it in the stub winsys any more. This
was breaking builds for backends using the stub winsys.
This migrates all the GLX window system code down from the Clutter
backend code into a Cogl winsys. Moving OpenGL window system binding
code down from Clutter into Cogl is the biggest blocker to having Cogl
become a standalone 3D graphics library, so this is an important step in
that direction.
