Since the Cogl 1.18 branch is actively maintained in parallel with the
master branch; this is a counter part to commit 1b83ef938fc16b which
re-licensed the master branch to use the MIT license.
This re-licensing is a follow up to the proposal that was sent to the
Cogl mailing list:
http://lists.freedesktop.org/archives/cogl/2013-December/001465.html
Note: there was a copyright assignment policy in place for Clutter (and
therefore Cogl which was part of Clutter at the time) until the 11th of
June 2010 and so we only checked the details after that point (commit
0bbf50f905)
For each file, authors were identified via this Git command:
$ git blame -p -C -C -C20 -M -M10 0bbf50f905..HEAD
We received blanket approvals for re-licensing all Red Hat and Collabora
contributions which reduced how many people needed to be contacted
individually:
- http://lists.freedesktop.org/archives/cogl/2013-December/001470.html
- http://lists.freedesktop.org/archives/cogl/2014-January/001536.html
Individual approval requests were sent to all the other identified authors
who all confirmed the re-license on the Cogl mailinglist:
http://lists.freedesktop.org/archives/cogl/2014-January
As well as updating the copyright header in all sources files, the
COPYING file has been updated to reflect the license change and also
document the other licenses used in Cogl such as the SGI Free Software
License B, version 2.0 and the 3-clause BSD license.
This patch was not simply cherry-picked from master; but the same
methodology was used to check the source files.
The previous implementation was dereferencing the sample pointer in
order to get the offset to subtract from the member pointer. The
resulting value is then only used to get a pointer to the member in
order to calculate the offset so it doesn't actually read from the
memory location and shouldn't cause any problems. However this is
probably technically invalid and could have undefined behaviour. It
looks like clang takes advantage of this undefined behaviour and
doesn't actually offset the pointer. It also generates a warning when
it does this.
This patch splits the _cogl_container_of macro into two
implementations. Previously the macro was always used in the list
iterator macros like this:
SomeType *sample = _cogl_container_of(list_node, sample, link)
Instead of doing that there is now a new macro called
_cogl_list_set_iterator which explicitly assigns to the sample pointer
with an initial value before assigning to it again with the real
offset. This redundant initialisation gets optimised out by compiler.
The second macro is still called _cogl_container_of but instead of
taking a sample pointer it just directly takes the type name. That way
it can use the standard offsetof macro.
https://bugzilla.gnome.org/show_bug.cgi?id=723530
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 1efed1e0a2bce706eb4901979ed4e717bb13e4e2)
Texture allocation is now consistently handled lazily such that the
internal format can now be controlled using
cogl_texture_set_components() and cogl_texture_set_premultiplied()
before allocating the texture with cogl_texture_allocate(). This means
that the internal_format arguments to texture constructors are now
redundant and since most of the texture constructors now can't ever fail
the error arguments are also redundant. This now means we no longer
use CoglPixelFormat in the public api for describing the internal format
of textures which had been bad solution originally due to how specific
CoglPixelFormat is which is missleading when we don't support such
explicit control over the internal format.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 99a53c82e9ab0a1e5ee35941bf83dc334b1fbe87)
Note: there are numerous API changes for functions currently marked
as 'unstable' which we don't think are in use by anyone depending on
a stable 1.x api. Compared to the original patch though this avoids
changing the cogl_texture_rectangle_new_with_size() api which we know
is used by Mutter.
The plan is to defer more of the work for creating a texture until
allocation time, but that means we won't be able to always assume
we can query the size of a texture when creating an offscreen
framebuffer from a texture (consider for example using
_texture_new_from_file() where the size isn't known until the file has
been loaded). This defers needing to know the size of the texture
underlying an offscreen framebuffer until calling
cogl_framebuffer_allocate().
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 9688e7dc1eeae3144729dfd4a4bf409620346bf4)
This renames cogl_offscreen_new_to_texture to
cogl_offscreen_new_with_texture. The intention is to then cherry-pick
this back to the cogl-1.16 branch so we can maintain a parallel
cogl_offscreen_new_to_texture() function which keeps the synchronous
allocation semantics that some clutter applications are currently
relying on.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit ecc6d2f64481626992b2fe6cdfa7b999270b28f5)
Note: Since we can't break the 1.x api on this branch this keeps a
thin shim around cogl_offscreen_new_with_texture to implement
cogl_offscreen_new_to_texture with its synchronous allocation
semantics.
This removes cogl-queue.h and adds a copy of Wayland's embedded list
implementation. The advantage of the Wayland model is that it is much
simpler and so it is easier to follow. It also doesn't require
defining a typedef for every list type.
The downside is that there is only one list type which is a
doubly-linked list where the head has a pointer to both the beginning
and the end. The BSD implementation has many more combinations some of
which we were taking advantage of to reduce the size of critical
structs where we didn't need a pointer to the end of the list.
The corresponding changes to uses of cogl-queue.h are:
• COGL_STAILQ_* was used for onscreen the list of events and dirty
notifications. This makes the size of the CoglContext grow by one
pointer.
• COGL_TAILQ_* was used for fences.
• COGL_LIST_* for CoglClosures. In this case the list head now has an
extra pointer which means CoglOnscreen will grow by the size of
three pointers, but this doesn't seem like a particularly important
struct to optimise for size anyway.
• COGL_LIST_* was used for the list of foreign GLES2 offscreens.
• COGL_TAILQ_* was used for the list of sub stacks in a
CoglMemoryStack.
• COGL_LIST_* was used to track the list of layers that haven't had
code generated yet while generating a fragment shader for a
pipeline.
• COGL_LIST_* was used to track the pipeline hierarchy in CoglNode.
The last part is a bit more controversial because it increases the
size of CoglPipeline and CoglPipelineLayer by one pointer in order to
have the redundant tail pointer for the list head. Normally we try to
be very careful about the size of the CoglPipeline struct. Because
CoglPipeline is slice-allocated, this effectively ends up adding two
pointers to the size because GSlice rounds up to the size of two
pointers.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 13abf613b15f571ba1fcf6d2eb831ffc6fa31324)
Conflicts:
cogl/cogl-context-private.h
cogl/cogl-context.c
cogl/driver/gl/cogl-pipeline-fragend-glsl.c
doc/reference/cogl-2.0-experimental/Makefile.am
This factors out all of the OpenGL specific code in cogl-texture-2d.c
into cogl-texture-2d-gl.c and where necessary adds indirection through
the CoglDriver vtable so that we can eventually start to experiment with
non-OpenGL backends for Cogl.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit ec57588671696bbe7ce714bdfe7324236146c9c0)
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.
This splits out most of the OpenGL specific code from cogl-framebuffer.c
into cogl-framebuffer-gl.c and extends the CoglDriverVtable interface
for cogl-framebuffer.c to use.
There are hopes to support several different backends for Cogl
eventually to hopefully get us closer to the metal so this makes some
progress in organizing which parts of Cogl are OpenGL specific so these
parts can potentially be switched out later.
The only remaining use of OpenGL still in cogl-framebuffer.c is to
handle cogl_framebuffer_read_pixels.
This commit introduces some new framebuffer api to be able to
enable texture based depth buffers for a framebuffer (currently
only supported for offscreen framebuffers) and once allocated
to be able to retrieve the depth buffer as a texture for further
usage, say, to implement shadow mapping.
The API works as follow:
* Before the framebuffer is allocated, you can request that a depth
texture is created with
cogl_framebuffer_set_depth_texture_enabled()
* cogl_framebuffer_get_depth_texture() can then be used to grab a
CoglTexture once the framebuffer has been allocated.
vtable
(Sorry, I had to re-apply Neil's patch as the original one somehow did
not apply)
The function prototypes for the GL functions in CoglContext have the
GLAPIENTRY attribute which on Windows makes them use the stdcall
calling convention. The function pointers exposed from cogl-gles2.h
don't have GLAPIENTRY so they end up having a different calling
convention on Windows. When Cogl is compiled there it ends up giving a
lot of warnings because it assigns a pointer to an incompatible
function type.
We probably don't want to make the functions exposed in cogl-gles2.h
use the stdcall calling convention because we control that API so
there is no need to introduce a second calling convention. The GLES2
context support currently isn't going to work on Windows anyway
because there is no EGL or GLES2 implementation.
Eventually if we make the Cogl GLES2 context virtualized on top of
Cogl then we will provide our own implementations of all these
functions so we can easily keep the C calling convention even on
Windows.
Until then to avoid the warnings on Windows we can just cast the
function pointers temporarily to (void*) when filling in the vtable.
This will also fix the build on Windows using Visual Studio, as it is
more picky on calling convention mismatches.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
There was a FIXME comment about making glCopyTex{Sub,}Image2D work
with CoglOffscreen buffers. This has already been fixed so we should
remove the comment.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 750e5668ee64a315c8090dd2223334b1e04bee54)
We don't need to split the wrapper snippet into two separate parts
because it should be ok to declare the flip uniform in the middle of
the shader as long as it is somewhere in the global scope. Therefore
we can just declare it right before the definition for the replacement
main function. This is important because we don't want to put anything
at the top of the application's shader in case it is using a
'#version' directive. In that case moving it to anything other than
the first line would break things.
This patch also adds a marker in a comment around the wrapper snippet
so that we can easily locate the snippet when glGetShaderSource is
called and remove it.
The wrapper for glGetAttachedShaders has been removed because there
are no longer any additional shaders attached to the program so we can
just let GL handle it directly.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit dbd92e24ae61dcbe7ef26f61c9117c5516a7fa87)
In our wrapper for glShaderSource we special case when a vertex shader
is being specified so we can sneak in a wrapper for the main function to
potentially flip all rendering upside down for better integration with
Cogl.
Previously we were appending the wrapper to all the sub-strings passed
via the vector of strings to glShaderSource but we now grow the vector
instead and insert the prelude and wrapper strings into the beginning
and end of the vector respectively so we should only have one copy for a
single shader.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit d2904d518718e3fbf4441abe2c2bcfd63edfd64b)
The SGX GLSL compiler refuses to accept shaders of the form:
void foo();
void bar() {
foo();
}
where foo is undefined at glShaderSource() time, left for definition at
link time. To work around this, simply append the wrapper shader to
user shaders, rather than building a separate shader that's always
linked with user shaders.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 96f02c445f763ace088be71dc32b3374b2cdbab2)
We want applications to fully control the lifetime of a CoglContext
without having to worry that internal resources (such as the default
2d,3d and rectangle textures, or any caches we maintain) could result in
circular references that keep the context alive. We also want to avoid
making CoglContext into a special kind of object that isn't ref-counted
or that can't be used with object apis such as
cogl_object_set_user_data. Being able to reliably destroy the context is
important on platforms such as Android where you may be required
bring-up and tear-down a CoglContext numerous times throughout the
applications lifetime. A dissadvantage of this policy is that it is now
possible to leave other object such as framebuffers in an inconsistent
state if the context is unreferenced and destroyed. The documentation
states that all objects that directly or indirectly depend on a context
that has been destroyed will be left in an inconsistent state and must
not be accessed thereafter. Applications (such as Android applications)
that need to cleanly destroy and re-create Cogl resources should make
sure to manually unref these dependant objects before destroying the
context.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 23ce51beba1bb739a224e47614a59327dfbb65af)
When the CoglGLES2Context is bound to read from a CoglOffscreen then
the result will be upside down from what GL expects if
glCopyTexImage2D is used directly. To fix that, this patch now wraps
glCopyTexImage2D and glCopyTexSubImage2D so that the copy is doing by
binding an FBO to the target texture and then rendering a quad
sampling from the texture in the offscreen framebuffer.
The rendering is done using the Cogl context rather than the GLES2
context because otherwise it would have to do a fair bit of work to
try and stash the old state on the context before setting up the state
to do the blit. The down side of this is that the contexts need to be
synchronized so that the rendering will be up-to-date. As far as I
understand from the GL spec, this requires a glFinish and then the
texture needs to be rebound in the new context because updates to
shared objects are guaranteed to be reflected until the object is
rebound.
GLES2 supports using glCopyTexImage2D for cube map textures. As Cogl
doesn't currently have support for cube maps, it is quite hard to get
that to work with this patch. For now attempts to copy to a cube map
texture will just be sliently ignored.
This patch also includes a test case which renders an image to the
framebuffer and then copies it to a texture. The texture is then
rendered back to the framebuffer and the contents are checked for the
correct orientation using glReadPixels.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 30b6da8134bad95267265e26685c7475f6c351c9)
This patch adds a hash table mapping texture object IDs to a struct so
that we can keep track of some of the state for each texture object.
Currently it will just track the width and height of the texture 2D
target.
Additionally it will now try to delete any texture objects that have
data created for them by the GLES2 context so that it won't leak them.
It only tracks objects that get data set on them, not all objects that
are bound because it is possible to use the GLES2 context with foreign
textures via cogl_gles2_texture_get_handle() and we don't want to
delete those.
In order to keep track of the currently bound texture object it also
needs to track the active texture unit.
Note that this state tracking will probably go wrong if GL throws an
error for invalid state. For example if glActiveTexture is called with
an invalid texture unit then GL will ignore the binding but Cogl will
assume it is valid and the state tracking will get out of sync.
Perhaps it would be good if Cogl could detect the errors but this is
difficult to do without consuming them.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit d8c72bb56cf3598fc57d629edc618f1bfa79f125)
Cogl has a different origin for texture coordinates than OpenGL so
that the results of rendering to a texture should leave the top of the
image at the texture coordinate 0,0 rather than the bottom. When a
GLES2 context is used to render to a Cogl texture via a CoglOffscreen
we don't really want the application to have to be aware of the
mismatch and flip the texture coordinates. To get that to work, this
patch now tracks all of the programs that the application generates
using the context and sneaks in an extra vertex shader with an
alternative main function. This main function multiplies the final
calculated gl_Position by a vector uniform which we can use to flip
the image. When the application uploads the source code for a vertex
shader we now replace any occurrences of the token 'main' with '_c31'
and this renamed function gets called from the replacement main
function. The token has a weird name so that it will be unlikely to
conflict with a variable name in the application's source but it also
needs to have the same number of characters as the original token so
that it won't affect column numbers in the error reporting.
We are also wrapping glGetShaderSource so that we can try to revert
the token name. The same goes for the error logs just in case the
error report mentions function names.
Both places that cause drawing to occur (glDrawElements and
glDrawArrays) are now also wrapped so that we can update the uniform
value whenever the program is used with a different type of
framebuffer from last time.
We additionally need to manually track the state for the viewport, the
stencil box and the front face because all of these will be affected
by whether we are flipping the image or not. Any attempts to change
these states will be queued and instead flushed at the last minute
before drawing.
There are still some known issues with this patch:
• glCopyTexImage2D and glCopyTexSubImage2D will do the wrong thing
when copying data from a CoglOffscreen. This could be quite fiddly
to solve.
• Point sprites won't flip correctly. To make this work we would need
to flip the gl_PointSprite builtin variable somehow. This is done in
the fragment shader not the vertex shader so flipping the calculated
gl_Position doesn't help here.
• The patch doesn't attempt to flip rendering to framebuffers for
textures created within the GLES2 context. This probably makes sense
because those textures are likely to be used within the GLES2
context in which case we want to leave the texture coordinates as
they are. However, if the texture is shared back out to Cogl with
cogl_gles2_texture_2d_new_from_handle then the texture will be
upside-down.
• The application can discover our secret uniform that we added via
glGetActiveUniform. It might be worth trying to disguise this by
wrapping that function although that could be quite fiddly.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit d589bf19e51f22c3241b2a18db10f22131ac126a)
All of the functions that create and destroy shaders are now wrapped
in the CoglGLES2Context so that we can track some extra data for them.
There are hash tables mapping object IDs to the corresponding data.
The data is currently not used for anything but will be in later
patches.
The glUseProgram, glAttachShader and glDetachShader functions
additionally need to be wrapped because GL does not delete shader
objects that are in use. Therefore we need to have a reference count
on the data so we can recognise when the last use has been removed.
The IDs are assumed to be specific to an individual CoglGLES2Context.
This is technically not the case because all of the CoglGLES2Contexts
are in the same share list. However we don't really want this to be
the case so currently we will assume sharing the object IDs between
contexts is undefined behaviour. Eventually we may want to actually
enforce this.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 05dc1e34785ae5f5484cd398ecc5464bd8bd3dcd)
In GL, the default viewport and scissor should be set to the size of
the first surface that the context is bound to. If a CoglGLES2Context
is first used with an offscreen framebuffer then this surface will
actually be the dummy 1x1 window which will mess up the defaults. To
fix that, this patch makes it just always override the viewport and
scissor the first time the context is bound to something.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 02567b3e6b64e6849b9f7c6aa2137401be7ece8d)
This makes it possible to integrate existing GLES2 code with
applications using Cogl as the rendering api.
Currently all GLES2 usage is handled with separate GLES2 contexts to
ensure that GLES2 api usage doesn't interfere with Cogl's own use of
OpenGL[ES]. The api has been designed though so we can provide tighter
integration later.
The api would allow us to support GLES2 virtualized on top of an
OpenGL/GLX driver as well as GLES2 virtualized on the core rendering api
of Cogl itself. Virtualizing the GLES2 support on Cogl will allow us to
take advantage of Cogl debugging facilities as well as let us optimize
the cost of allocating multiple GLES2 contexts and switching between
them which can both be very expensive with many drivers.
As as a side effect of this patch Cogl can also now be used as a
portable window system binding API for GLES2 as an alternative to EGL.
Parts of this patch are based on work done by Tomeu Vizoso
<tomeu.vizoso@collabora.com> who did the first iteration of adding GLES2
API support to Cogl so that WebGL support could be added to
webkit-clutter.
This patch adds a very minimal cogl-gles2-context example that shows how
to create a gles2 context, clear the screen to a random color and also
draw a triangle with the cogl api.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 4bb6eff3dbd50d8fef7d6bdbed55c5aaa70036a8)
