Otherwise, X11 identifiers may leak and cause havoc in big applications
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit ed0cdca0eca815543619fe72fbd42d662d53f92d)
When multiplying two quaternions, we now implicitly copy the components
of the 'a' argument so that the result can be reliably written back to
the 'a' argument quaternion without conflicting with the multiplication
itself. This is consistent with the cogl_matrix_multiply() api which
allows the 'result' and 'a' arguments to point to the same matrix. In
debug builds Cogl will assert that the 'b' and 'result' arguments don't
point to the same quaternion.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 207527313a8957789390069e84189254cf41e88f)
When freeing a CoglOnscreen we weren't freeing the state associated with
swap notification callbacks.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 70bc12fe20fa1be4eac58356861a730f18d6b59e)
This fixes _cogl_memory_stack_free to ensure we don't dereference freed
memory as we iterate the sub-stacks to free them.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 1d27fedef9c599aa9976b809f18e0da1913cec26)
This adds api to be able to request that the window system allows a
given onscreen framebuffer to be resizable, and api to add and remove
resize handlers to be called whenever the framebuffer does actually
change size.
The new functions are:
cogl_onscreen_{get,set}_resizable()
cogl_onscreen_{add,remove}_resize_handler()
The examples cogl-hello and cogl-x11-foreign have been updated to use
the new api. To smoke test how Cogl updates the viewport automatically
in response to window resizes the cogl-hello test doesn't explicitly
respond to resize events by setting the viewport and cogl-x11-foreign
responds by setting a viewport that is offset by a quarter of the
window's width/height and half the width and height of the window.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit a1a8cc00bfa2cecaf1007aec5f3dd95dc07b1786)
-The test program and examples must be linked to SDL too when COGL is
built with the SDL renderer, so add configs accordingly.
-Also use Multibyte character sets (i.e. don't -DUNICODE) for all configs,
like what GLib does, for consistency.
-Fix the VS2010 property sheets that was accidently malformed.
(cherry picked from commit 9ed541b4e35208df87ffaa5fbbb39e11e8c247ef)
The command to copy cogl-gl-header.h from the pre-configured
cogl-gl-header.h.win32 is wrong. Fix that.
Also add -DCOGL_ENABLE_EXPERIMENTAL_API for all creations of the cogl.def
(cherry picked from commit 6df152c411749a610a57ecaab6a983b51d2a7612)
There is currently a known bug where when rendering offscreen point
sprites will be rendered upside-down. For that reason
test-point-sprite is marked as a known failure because it checks the
orientation of the point sprites and the conformance test suite is
rendered to offscreen buffers by default. However this doesn't help to
catch more general failures that stop the point sprites being rendered
at all. To fix this the test-point-sprite test has been split into two
tests, one which verifies the orientation and one which does not. The
two tests are in the same source file and internally share the same
static function but pass a flag to specify whether to check the
orientation. If the orientation should be ignored then it will create
a 2x1 texture instead of a 2x2 texture so that it will appear the same
regardless of whether it is upside-down. The checks for the colors
have been altered accordingly.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 51b7fdbe17f300cf2edf42c2ca740ad748c9fd78)
When using the GLES2 driver with a pipeline layer that has point
sprite coordinates enabled it extracts the texture coordinates from
the gl_PointCoord builtin instead of cogl_tex_coord_in[*].
gl_PointCoord is not quite the same as the regular texture coordinates
because it is only a vec2 instead of a vec4. This used to work ok
because either set of texture coordinates would always immediately be
accessed using a swizzle of '.st' so it would effectively be converted
to a vec2 anyway. However since the snippet hook for texture lookups
was added the texture coordinates are now passed to a function to
perform the actual lookup instead. This function always takes a vec4
so the shader would not compile. This patch fixes it to construct a
vec4 from gl_PointCoord by setting the third and fourth components to
0.0 and 1.0.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit cb3409b23caf324a548f82cfb88acc684cc71930)
Otherwise, if a texture is created before all the other FBOs, a new
atlas will be created, with a FBO with COGL_OFFSCREEN_DISABLE_DEPTH_AND_STENCIL
causing last_offscreen_allocate_flags to be 0.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 7d2156785da8196e129eb393efb0d09093c4783e)
This adds some android specific api for creating a CoglBitmap from an
Android asset.
As part of the work it also seemed like a good time to change the
internal bitmap constructors to take an explicit CoglContext argument
and so the public cogl_bitmap_new_from_file() api was also changed
accordingly to take a CoglContext pointer as the first argument.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 099d6d1b505b55bbd09c50d081deb41ab5764e19)
Since we aren't able to break APIs on the 1.12 branch this cherry-pick
skips the change to cogl_bitmap_new_from_file()
wingdi.h which gets included from windows.h #defines ERROR to 0 so we
can't use it as a label in Cogl. This patch changes it to be error in
lower case instead.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit e9bac2755c2cba84c82a856d369a30560d19a32e)
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.
According to the GLES1/2 spec, the transpose argument of
glUniformMatrix* should always be FALSE. Cogl directly exposes the
transposedness of the uniform value in
cogl_pipeline_set_uniform_matrix and we were previously passing this
value on to GL. This patch makes it instead just always transpose the
matrix in Cogl itself when copying the value to the CoglBoxedValue. It
doesn't seem like there could be much advantage to letting GL
transpose the uniform value and at least Mesa just does a very similar
loop to handle the transpose.
Mesa has started being more pedantic about this which was making
test_pipeline_uniforms fail.
http://cgit.freedesktop.org/mesa/mesa/commit/?id=60e8a4944081b42127b3
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit f42ee670ff663d03073d6b1038b21a0aa1b3ec2b)
Comments are interpreted as docbook snippets and <pre> is from html. The
closest maching tag for inline content seems to be <literal>.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 66c9f26dfb3133f43d319128d6636f793a1ceb4a)
The first argument has been removed from the function. Update the
example accordingly.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 06e47af3144565bdf85abf8ae561c7ceeafa2cbc)
You had a mismatch between the file name in -sections.txt and
-docs.xml.in. Chose cogl-sdl.xml.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 8b61963f3015e11bd5fbe225ec566ac6e354acc1)
Contrary to the other inversion functions, invert_matrix_3d() does not
initialize the inverse to the identity and then only touches the
elements it cares about. Problem is the ww component is left alone,
which makes everything go to a black hole when using an inverse matrix
as the transform matrix of a framebuffer.
This is how cameras are typically implemented, they have a transform
and the framebuffer matrix stack is initialized with the inverse
of that transform. A gdb session gives away what happens:
The camera model view matrix, slightly rotation around the X axis:
camera mv 1.000000 0.000000 0.000000 0.000000
camera mv 0.000000 0.984808 -0.173648 0.000000
camera mv 0.000000 0.173648 0.984808 10.000000
camera mv 0.000000 0.000000 0.000000 1.000000
Breakpoint 5, invert_matrix_3d (matrix=0x8056b58) at ./cogl-matrix.c:671
671 const float *in = (float *)matrix;
(gdb) p *matrix
$1 = {xx = 1, yx = 0, zx = 0, wx = 0, xy = 0, yy = 0.98480773,
zy = 0.173648164, wy = 0, xz = 0, yz = -0.173648164, zz = 0.98480773,
wz = 0, xw = 0, yw = 0, zw = 10, ww = 1, inv = {0 <repeats 16 times>},
type = 6, flags = 1030, _padding3 = 0}
(gdb) finish
Run till exit from #0 invert_matrix_3d (matrix=0x8056b58)
at ./cogl-matrix.c:671
0x00141ced in _cogl_matrix_update_inverse (matrix=0x8056b58)
at ./cogl-matrix.c:1123
1123 if (inv_mat_tab[matrix->type](matrix))
Value returned is $2 = 1
(gdb) p *matrix
$3 = {xx = 1, yx = 0, zx = 0, wx = 0, xy = 0, yy = 0.98480773,
zy = 0.173648164, wy = 0, xz = 0, yz = -0.173648164, zz = 0.98480773,
wz = 0, xw = 0, yw = 0, zw = 10, ww = 1, inv = {1, 0, 0, 0, 0, 0.98480773,
-0.173648164, 0, 0, 0.173648164, 0.98480773, 0, -0, -1.73648167,
-9.84807777, 0}, type = 6, flags = 1030, _padding3 = 0}
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 9a19ea0147eb316247c45cbba6bb70dec5b9be4c)
Some drivers have good support for GLSL but don't have the complete
set of features needed to advertise GL 2.0 support. We should accept
the three old GLSL extensions (GL_ARB_shader_objects,
GL_ARB_vertex_shader and GL_ARB_fragment_shader) to support shaders on
these drivers.
This patch splits the shader functions into four sections :- those
that are provided only in GL 2.0, those that have the same name in the
shader objects extension, those that are provided by the vertex
shader extension (they all share the same name) and those that have a
different name in the shader objects extension.
If GL 2.0 is not supported but all three of the extensions are then
the pointers to the GL2-only functions will be replaced to point to
the equivalent functions from the extensions. That way the rest of the
Cogl source doesn't have to worry about the name differences.
https://bugzilla.gnome.org/show_bug.cgi?id=677078
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 71ecb51bd20dc3053b4221961b57e5a2b1029bdf)
If cogl_pipeline_remove_layer is called on a copied pipeline to remove
a parent layer then it will still end up calling
_cogl_pipeline_remove_layer_difference on the layer. This function
was directly trying to remove the layer from the pipeline's list of
layer differences. However in the child pipeline the layer isn't in
the list because it is unchanged from its parent. The function had an
assertion to verify that this situation wasn't hit so in a debug build
it would just bail out.
This patch removes the assertion and changes it to only remove the
layer if it is owned by the pipeline. Otherwise it just sets the
COGL_PIPELINE_STATE_LAYERS difference as normal and decrements the
number of layers. This will cause it to successfully remove the layer
because either it is the last layer in which case it will be ignored
after n_layers is decreased or if it is in the middle of the list then
the subsequent layers will all be shifted down so there will be a
replacement layer difference.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 88e73dd93fa09a158064a946ab229591a5888b97)
The test creates a pipeline with two layers which add two different
color constants together and then tries various combinations of
removing the layers and checks that it gets the right color.
Currently this is failing if a pipeline is copied and then a layer is
removed from the copy.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 844440a5cee5907c4d61e995804534ac0613bb0f)
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)
When having the [0, 0, 0] vector, normalize() won't try to divide by 0
and thus it's always safe to use that funtion.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 64370e7ddd32f25556a1792c00d14adc48a81d45)
Until now, we hardcoded the internal format to GL_RGBA and used the
internal format returned by pixel_format_to_gl() as the format for
checking the texture size and format we're asked to create.
Let's use the proper internal format/format from now on.
This is needed as a later patch introduces DEPTH and DEPTH_STENCIL
textures.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit ec45f60ee2545f88302da314bcdbe1439c4ba9c9)
The usual suspects (more examples ans tests, generated headers) and the
documentation updated to the cogl2 name.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 90b07230692d3fb36ea18c651ae120e472b5380e)
Missing bit of 4bb6eff3dbd50d8fef7d6bdbed55c5aaa70036a8
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 1674cf28f1f5b71bd25a1f253c99825d427dd243)
The y translation was being initialised with the z value and the z
translation was being left as 0.0.
(cherry picked from commit b44feb617ecb9cbf7d53f0d745f686c17ef3246d)
When rendering the debug wireframe Cogl generates a child pipeline of
the application's pipeline to replace the fragment processing.
Previously it was creating a new snippet every time something was
drawn. Cogl doesn't attempt to compare the contents of snippets when
looking in the program cache for a matching pipeline so this would
cause it to generate a new program for every primitive. It then quite
quickly ends printing the warning about there being more than 50
programs in the cache. To fix that this patch makes it cache the
snippet so that Cogl can successfully recognise that it already has a
program generated for the new pipeline.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit c4bb08ee8767b5320980dba10b20921393cb5613)
Previously the CoglDrawFlags passed to
_cogl_framebuffer_draw_indexed_attributes when drawing is redirected
to draw a wireframe are overriden to avoid validating the pipeline,
flushing the framebuffer state and flushing the journal. This ends up
breaking scenes that only contain models drawn from attributes in the
application because nothing will flush the matrices. It seems to make
more sense to just use whatever draw flags were passed from the
original draw command so that it will flush the matrices if the caller
was expecting it.
One problem with this is that if the wireframe causes the journal to
be flushed then it will already have temporarily disabled the
wireframe debug flag so the journal will not be drawn with wireframes.
To fix this the patch adds a CoglDrawFlag to disable the wireframe and
uses that instead of disabling the debug flag.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 283f6733e63ba65d9921f45868edaabbd9420a61)
Previously if an application does not use the matrix stack as a stack
but instead just loads its own matrices for each frame using
cogl_framebuffer_set_modelview_matrix then it will continously push
OP_LOAD entries on the stack and the stack will grow forever. This
patch fixes that use case by resetting the top of the stack to the
last save entry whenever something is pushed that replaces the
previous matrix on the stack.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit d31ed33241a9e9e3bc25f01b2614678827a7a9aa)
This adds some preliminary testing for eulers and quaternions. It
mostly just tests the cogl_matrix_init_from_{quaternion,euler}
functions as well as applying a euler or quaternion transformation to
a framebuffer's modelview matrix.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit a32eb76e16d7d76af2fe8a6ba9151d8826b58864)
This adds the following new functions to apply a rotation described by
a euler or a quaternion to either a CoglMatrix or directly to the
modelview stack of a framebuffer:
cogl_matrix_rotate_quaternion
cogl_matrix_rotate_euler
cogl_framebuffer_rotate_quaternion
cogl_framebuffer_rotate_euler
The direct framebuffer functions have corresponding functions in the
CoglMatrixStack to store an entry describing the rotation.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 5064315678b496395e1d01f266f322d73e55e324)
The _cogl_matrix_entry_equal function has a large switch statement to
do the right kind of comparison for the entry. However most of the
entries have a return statement that is only conditionally reached.
There were no corresponding break statements to the case labels so
presumably if the comparison succeeded for the correct entry type it
would also flow through and try the comparison for the next type which
would be extremely unlikely to pass.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 339db0f9cc3ee2bee4c56f9cb05dcb4ddd6815ed)
This creates a matrix to represent the given euler rotation. This
should be more efficient than creating the matrix by doing three
separate rotations because no separate intermediate matrices are
created and no matrix multiplication is needed.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit e66d9965897999a4889063f6df9a20ea6abf97fe)
The quaternion is not modified so for consistency with the rest of the
API it should probably be const.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 7fa8c05c2ffb90cba03289a04e37866efc0890a5)
The documentation for cogl_quaternion_init_from_array contradicts
itself and says that the array is w,x,y,z in one part but x,y,z,w in
another. This fixes it to say w,x,y,z in both parts.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit b08a81e5dfb05fec867c08c689237fae937341ad)
When --disable-debug is passed to the configure script it was actually
still defining COGL_ENABLE_DEBUG so very little would end up being
disabled. If COGL_ENABLE_DEBUG actually got defined it would also fail
to compile because _cogl_debug_instances and COGL_DEBUG_N_LONGS from
cogl-debug.h were only defined if debugging is enabled but they are
used regardless.
This patch also makes it so that the _COGL_RETURN_IF_FAIL family of
macros that are used when glib support is disabled are now disabled if
debugging is disabled. When the glib macros are used they are already
disabled because we additionally define G_DISABLE_CHECKS.
'COGL_HANDLE_DEBUG' has been removed from the list of defines passed
when debugging is enabled because CoglHandle has already been removed
and it is not used anywhere in the code.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 9811a0101c9cbb4ab95c55a2b41fd10ff4c77d9f)
test-gles2-context was giving a warning because printf was being used
without including stdio.h. This changes it to use g_print and to first
check for g_test_verbose().
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 9f4945e3daa693e1aa56fe4c1ce37fcc545f8558)
The cogl-gles2-gears example will fail to build unless
--enable-cogl-gles2 is enabled in the configure script because it
depends on libcogl-gles2. This patch makes it only conditionally build
the example depending on the BUILD_COGL_GLES2 automake conditional.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 7f57e9c444b6353ac17e920ea4fc63ebe3cc29d3)
