We use the micro version for distinguishing released tarballs and Git
builds; the maintainer compiler flags should be enabled for the latter,
and not just for unstable cycles, since it makes sense to have extra
warning flags even on stable cycles.
We also want to allow people to turn on -Werror on demand, so let's add
a third option to --enable-maintainer-flags.
When pushing a framebuffer it would previously push
COGL_INVALID_HANDLE to the top of the framebuffer stack so that when
it later calls cogl_set_framebuffer it will recognise that the
framebuffer is different and replace the top with the new
pointer. This isn't ideal because it breaks the code to flush the
journal because _cogl_framebuffer_flush_journal is called with the
value of the old pointer which is NULL. That function was checking for
a NULL pointer so it wouldn't actually flush. It also would mean that
if you pushed the same framebuffer twice we would end up dirtying
state unnecessarily. To fix this cogl_push_framebuffer now pushes a
reference to the current framebuffer instead.
After a dependent framebuffer is added to a framebuffer it was never
getting removed. Once the journal for a framebuffer is flushed we no
longer depend on any framebuffers so the list should be cleared. This
was causing leaks of offscreens and textures.
Unlike glXSwapBuffers, glXCopySubBuffer and glBlitFramebuffer don't
issue an implicit glFlush() so we have to flush ourselves if we want the
request to complete in finite amount of time since otherwise the driver
can batch the command indefinitely.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2551
This adds a note to clarify that cogl_matrix_multiply allows you to
multiply the @a matrix in-place, so @a can equal @result but @b can't
equal @result.
When uploading the layer matrix to GL it wasn't first calling
glActiveTextureMatrix to set the right texture unit for the
layer. This would end up setting the texture matrix on whatever layer
happened to be previously active. This happened to work for
test-cogl-multitexture presumably because it was coincidentally
setting the layer matrix on the last used layer.
This adds a conformance test which paints using a pipeline that has
two layers containing textures. Each layer has a different user
matrix. When the two layers are combined with the right matrices then
all of the colors end up white. The test then verifies this by reading
back the pixels.
As the prelude to deprecation of the function in 1.8, let's move the
implementation to an internal function, and use that instead of the
public facing one.
The venerable test-actors used the default stage, which meant that
closing the window just stopped the main loop but left the scene intact.
This does not happen with a normal stage created through
clutter_stage_new().
The change happened in 6ed6b2a54b, in an
unhelpfully named commit that was just supposed to switch to static
colors. My bad.
Anyway, the change led to some assertion failures when closing the stage
in the middle of an animation.
The correct thing to do when using an actor from another object (a
Timeline ::new-frame callback in this case) without owning the instance
is to connect to the ::destroy signal and clean up the pointer to avoid
calling an invalid actor.
The GQueue that stores the global events queue is handled all over the
place:
• the structure is created in _clutter_backend_init_events();
• the queue is handled in clutter-event.c, clutter-stage.c and
clutter-backend.c;
• ClutterStage::dispose cleans up the events associated with
the stage being destroyed;
• the queue is destroyed in ClutterBackend::dispose.
Since we need to have access to it in different places we cannot put it
inside ClutterBackendPrivate, hence it should stay in ClutterMainContext;
but we should still manage it from just one place - preferably by the
ClutterEvent API only.
In the future, we want event translators to be the way to handle events
in backends. For this reason, they should be a part of the base abstract
ClutterBackend class, and not an X11-only concept.
Instead of asking all backends to do that for us, we can call
ClutterStageWindow::redraw ourselves by default.
This changeset fixes all backends to actually do the right thing, and
move the stage implementation redraw inside the ClutterStageWindow
implementation itself.
We need to *write* to the shared memory, not read from it.
cogl_texture_from_data() is read-only, it doesn't keep
the data in sync with the texture.
Instead, we have to call cogl_texture_get_data() ourselves
to sync manually.
eglGetProcAddress() returns non-null function pointers
whether or not they're actually supported by the driver,
since it can be used before any driver gets loaded. So
we have to check if the extensions are advertised first,
which requires having an initialized display, so we split
the display creation code into its own function.
The exception to extension-checking is EGL_MESA_drm_display,
since by definition it's needed before any display is even
created.
Show how to animate an actor using a ClutterPathConstraint.
This demonstrates how to get effects similar to
ClutterPathBehaviour with the modern animation APIs.
Includes 3 examples:
1) Simple ClutterPathConstraint used with implicit animations
2) ClutterPathConstraint used to simulate circular animation,
using ClutterAnimator
3) Creating simple curved path animations with non-linear
easing
Use both the MappingNotify event and the XKB XkbMapNotify event, if
we're compiled with XKB support.
This change is also useful for making ClutterKeymapX11 an event
translator and let it deal with XKB events internally like we do for
stage and input events.
Based on a patch by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off by: Emmanuele Bassi <ebassi@linux.intel.com>
http://bugzilla.clutter-project.org/show_bug.cgi?id=2525
The redraw function might be called during destruction phase, when the
Stage state has not entirely been tore down. We need to be slightly more
resilient to that scenario.
The pipeline private data is accessed both from the private data set
on a CoglPipeline and the destroy notify function of a weak material
that the vertex buffer creates when it needs to override the wrap
mode. However when a CoglPipeline is destroyed, the CoglObject code
first removes all of the private data set on the object and then the
CoglPipeline code gets invoked to destroy all of the weak children. At
this point the vertex buffer's weak override destroy notify function
will get invoked and try to use the private data which has already
been freed causing a crash.
This patch instead adds a reference count to the pipeline private data
stuct so that we can avoid freeing it until both the private data on
the pipeline has been destroyed and all of the weak materials are
destroyed.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2544
In cogl_pipeline_set_layer_combine_constant it was comparing whether
the new color is the same as the old color using a memcmp on the
constant_color parameter. However the combine constant is stored in
the layer data as an array of four floats but the passed in color is a
CoglColor (which is currently an array of four guint8s). This was
causing valgrind errors and presumably also the check for setting the
same color twice would always fail.
This patch makes it do the conversion to a float array upfront before
the comparison.
Instead of just setting the input device pointer in the private event
data, it should also set the field in the event sub-types, so that
direct access to the structures still works.
We should force building the cookbook when releasing a tarball of
Clutter, so that users of packaged tarballs can actually build the
cookbook themselves.
Try to make the cookbook pass the distcheck phase, so that we can run
distcheck with --enable-docs, and make sure that a tarballed clutter
release can actually build the cookbook.
cogl_matrix_project_points and cogl_matrix_transform_points had an
optimization for the common case where the stride parameters exactly
match the size of the corresponding structures. The code for both when
generated by gcc with -O2 on x86-64 use two registers to hold the
addresses of the input and output arrays. In the strided version these
pointers are incremented by adding the value of a register and in the
packed version they are incremented by adding an immediate value. I
think the difference in cost here would be negligible and it may even
be faster to add a register.
Also GCC appears to retain the loop counter in a register for the
strided version but in the packed version it can optimize it out and
directly use the input pointer as the counter. I think it would be
possible to reorder the code a bit to explicitly use the input pointer
as the counter if this were a problem.
Getting rid of the packed versions tidies up the code a bit and it
could potentially be faster if the code differences are small and we
get to avoid an extra conditional in cogl_matrix_transform_points.
