The Wayland winsys defines functions declared in
cogl-wayland-renderer.h so it should include the header to make sure
the declarations are right. This was breaking because currently the
header #defines the _EXP suffixes on to the function names so it would
end up exporting the wrong symbol names.
We currently check for the IN_DESTRUCTION flag inside the
add_child_internal() function.
This check disallows calling methods that change the stacking order
within the destruction sequence, by triggering a critical warning first,
and leaving the actor in an undefined state, which then ends up being
caught by an assertion.
The reproducible sequence is:
- actor gets destroyed;
- another actor, linked to the first, will try to change the
stacking order of the first actor;
- changing the stacking order is a composite operation composed
by the following steps:
1. ref() the child;
2. remove_child_internal(), which removes the reference;
3. add_child_internal(), which adds a reference;
- the state of the actor is not changed between (2) and (3), as
it could be an expensive recomputation;
- if (3) bails out, then the actor is in an undefined state, but
still alive;
- the destruction sequence terminates, but the actor is unparented
while its state indicates being parented instead.
- assertion failure.
The obvious fix would be to decompose each set_child_*_sibling() method
into proper remove_child()/add_child(), with state validation; this may
cause excessive work, though, and trigger a cascade of other bugs in
code that assumes that a change in the stacking order is an atomic
operation.
Another potential fix is to just remove this check here, and let code
doing stacking order changes inside the destruction sequence of an actor
continue doing the work.
The third fix is to silently bail out early from every
set_child_*_sibling() and set_child_at_index() method, and avoid doing
work.
I have a preference for the second solution, since it involves the least
amount of work, and the least amount of code duplication.
See bug: https://bugzilla.gnome.org/show_bug.cgi?id=670647
This solves a crash on GNOME Shell, as compute the extents
for some StWidgets could lead to call st_widget_get_theme_node,
and it is a fatal error to call this on a widget that it not
beed added to a stage.
Make it like the clutter-version.h.in template. Since we aren't having
Windows-specific items in here (such as CLUTTER_FLAVOUR), perhaps we
could get the dllexport stuff in clutter-version.h.in, where it can be
used when necessary, and this file would be gone.
GLib introduced macros that allows defining the lower and upper bounds
of the API to be used by application code.
The lower bound allows to define the minimum version that will trigger
deprecation warnings; the upper bound defines the maximum version that
will trigger compiler warnings for unavailable symbols.
This scheme allows gradually porting application code to a new version
of the API, especially in case of resynchronization after multiple
development cycles.
It's the conformance test suite: there's no need to namespace the files,
just like there's no need to namespace the units.
This commit does not change the Cogl tests: they will be moved to Cogl
over time, and it's easier to do if we leave them as they are.
Now that ClutterActor has a default paint volume, subclasses may wish
to retrieve it without chaining up to the parent's implementation of
the get_paint_volume() function.
The get_default_paint_volume() returns a ClutterPaintVolume pointer
to the paint volume as computed by the default implementation of the
get_paint_volume() virtual function; it can only be used immediately,
as it's not guaranteed to survive across multiple frames.
Creating PaintVolume instances is not possible, and it's not recommended
anyway. It is, though, necessary to union paint volumes, especially with
2D boxes, in some cases.
Clutter should provide a simple convenience function that allows
unioning volumes to boxes in a moderately efficient way.
https://bugzilla.gnome.org/show_bug.cgi?id=670021
This patch reworks our conformance testing framework because it seems
that glib's gtesting framework isn't really well suited to our use case.
For example we weren't able to test windows builds given the way we
were using it and also for each test we'd like to repeat the test
with several different environments so we can test important driver and
feature combinations.
This patch instead switches away to a simplified but custom approach for
running our unit tests. We hope that having a more bespoke setup will
enable us to easily extend it to focus on the details important to us.
Notable changes with this new approach are:
We can now run 'make test' for our mingw windows builds.
We've got rid of all the test-*report* make rules and we're just left
with 'make test'
'make test' now runs each test several times with different driver and
feature combinations checking the result for each run. 'make test' will
then output a concise table of all of the results.
The combinations tested are:
- OpenGL Fixed Function
- OpenGL ARBfp
- OpenGL GLSL
- OpenGL No NPOT texture support
- OpenGLES 2.0
- OpenGLES 2.0 No NPOT texture support
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This adds api for explicitly choosing what underlying driver cogl should
use internally for rendering as well as api for querying back what
driver is actually in use.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
