This remove cogl-internal.h in favour of using cogl-private.h. Some
things in cogl-internal.h were moved to driver/gl/cogl-util-gl-private.h
and the _cogl_gl_error_to_string function whose prototype was moved from
cogl-internal.h to cogl-util-gl-private.h has had its implementation
moved from cogl.c to cogl-util-gl.c
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 01cc82ece091aa3bec4c07fdd6bc9e5135fca573)
This fixes some problems which were stopping --disable-glib from
working properly:
• A lot of the public headers were including glib.h. This shouldn't be
necessary because the API doesn't expose any glib types. Otherwise
any apps would require glib in order to get the header.
• The public headers were using G_BEGIN_DECLS. There is now a
replacement macro called COGL_BEGIN_DECLS which is defined in
cogl-types.h.
• A similar fix has been done for G_GNUC_NULL_TERMINATED and
G_GNUC_DEPRECATED.
• The CFLAGS were not including $(builddir)/deps/glib which was
preventing it finding the generated glibconfig.h when building out
of tree.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 4138b3141c2f39cddaea3d72bfc04342ed5092d0)
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)
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)
Cogl already had a vtable for the texture driver. This ended up being
used for some things that are not strictly related to texturing such
as converting between pixel formats and GL enums. Some other functions
that are driver dependent such as updating the features were not
indirected through a vtable but instead switched directly by looking
at the ctx->driver enum value. This patch normalises to the two uses
by adding a separate vtable for driver functions not related to
texturing and moves the pixel format conversion functions to it from
the texture driver vtable. It also adds a context parameter to all of
the functions in the new driver vtable so that they won't have to rely
on the global context.
This adds a public function to read pixels from a framebuffer into a
CoglBitmap. This replaces the internal function
_cogl_read_pixels_with_rowstride because a CoglBitmap contains a
rowstride so it can be used for the same purpose. A CoglBitmap already
has public API to make one that points to a CoglPixelBuffer so this
function can be used to read pixels into a PBO. It also avoids the
need to push the framebuffer on to the context's stack so it provides
a function which can be used in the 2.0 API after the stack is
removed.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
There are a few places in Cogl that try to set the premult bit on a
pixel format depending on whether it has an alpha channel. However
this breaks if the pixel format is alpha-only because premultiplying
data without any RGB components doesn't make any sense. This adds an
internal macro to check for cases where we should add the premult bit
called COGL_PIXEL_FORMAT_CAN_HAVE_PREMULT. This now gets used in all
places that previously just checking for COGL_A_BIT.
https://bugzilla.gnome.org/show_bug.cgi?id=671016
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This adds an internal utility function
_cogl_pixel_format_is_endian_dependant() that can query whether
accessing the components of a given format depends on the endianness of
the current host CPU or whether a pixel can be loaded as a word and
channels accessed using bit masking and shifting.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This moves _cogl_get_format_bpp from cogl-bitmap.c to cogl.c and renames
it to _cogl_pixel_format_get_bytes_per_pixel. This makes it clearer that
it doesn't return bits per pixel and makes the naming consistent with
other cogl api. The prototype has been moved to cogl-private.h since it
seems we should be aiming to get rid of cogl-internal.h at some point.
The patch also adds a simple gtk-doc comment since we might want to make
this api public.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Some code in Cogl such as when flushing a stencil clip assumes that it
can push a temporary simple pipeline to reset to a known state for
internal drawing operations. However this breaks down if the
application has set any legacy state because that is set globally so
it will also get applied to the internal pipeline.
_cogl_draw_attributes already had an internal flag to disable applying
the legacy state but I think this is quite awkward to use because not
all places that push a pipeline draw the attribute buffers directly so
it is difficult to pass the flag down through the layers.
Conceptually the legacy state is meant to be like a layer on top of
the purely pipeline-based state API so I think ideally we should have
an internal function to push the source without the applying the
legacy state. The legacy state can't be applied as the pipeline is
pushed because the global state can be modified even after it is
pushed. This patch adds a _cogl_push_source() function which takes an
extra boolean flag to mark whether to enable the legacy state. The
value of this flag is stored alongside the pipeline in the pipeline
stack. Another new internal function called
_cogl_get_enable_legacy_state queries whether the top entry in the
pipeline stack has legacy state enabled. cogl-primitives and the
vertex array drawing code now use this to determine whether to apply
the legacy state when drawing. The COGL_DRAW_SKIP_LEGACY_STATE flag is
now removed.
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 a _cogl_init function for Cogl that we expect to be the first
thing called before anything else is done with Cogl. It's not a public
API so it's expected that all entry points for Cogl that might be the
first function used should call _cogl_init().
We currently call _cogl_init() in these functions:
cogl_renderer_new
cogl_display_new
cogl_context_new
cogl_android_set_native_window
_cogl_init() can be called multiple times, and only the first call has
any affect.
For example _cogl_init() gives us a place check and parse the COGL_DEBUG
environment variable.
Since we don't have any need to parse command line arguments (we can
always get user configuration options from the environment) our init
function doesn't require argc/argv pointers.
By saying up front that we aren't interested in command line arguments
that means we can avoid the mess that is GOption based library
initialization which is extremely fragile due to its lack of dependency
tracking between modules.
Signed-off-by: Neil Roberts <neil@linux.intel.com>
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.
This gives us a way to clearly track the internal Cogl API that Clutter
depends on. The aim is to split Cogl out from Clutter into a standalone
3D graphics API and eventually we want to get rid of any private
interfaces for Clutter so its useful to have a handle on that task.
Actually it's not as bad as I was expecting though.
This is the same as _cogl_read_pixels except that it takes a rowstride
parameter for the destination buffer. Under OpenGL setting the
rowstride this will end up calling GL_ROW_LENGTH so that the buffer
region can be directly written to. Under GLES GL_ROW_LENGTH is not
supported so it will use an intermediate buffer as it does if the
format is not GL_RGBA.
cogl_read_pixels now just calls the full version of the function with
the rowstride set to width*bpp.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2414
Flushing the clip state no longer does anything that would cause the
journal to flush. The clip state is only flushed when flushing the
framebuffer state and in all cases this ends up flushing the journal
in one way or another anyway. Avoiding flushing the journal will make
it easier to log the clip state in the journal.
Previously when trying to set up a rectangle clip that can't be
scissored or when using a path clip the code would use cogl_rectangle
as part of the process to fill the stencil buffer. This is now changed
to use a new internal _cogl_rectangle_immediate function which
directly uses the vertex array API to draw a triangle strip without
affecting the journal. This should be just as efficient as the
previous journalled code because these places would end up flushing
the journal immediately before and after submitting the single
rectangle anyway and flushing the journal always creates a new vbo so
it would effectively do the same thing.
Similarly there is also a new internal _cogl_clear function that does
not flush the journal.
