The timeline base test unit is pretty slow, and under heavy load it will
tend to fail because of skipped frames. We should put it under
conditional testing and only run it if `-m slow` is passed to the test
harness.
Timeouts and idles are subject to the whims of the load of the machine
running the tests, as we found out with the new installed tests and
OSTree-based VM running the conformance test suite continuously.
We should be able to use a repaint function and a blocking loop that
either is terminated because we hit g_assert(), or because a flag gets
toggled once we know that the Stage has been at least painted once.
The currently enabled tests using clutter_stage_read_pixels() have been
updated to this approach.
https://bugzilla.gnome.org/show_bug.cgi?id=703476
If we don't have support for offscreen buffers, then there's no point in
testing FBO support in ClutterTexture — a feature that has been long
since deprecated, on a deprecated class.
This reverts commit 2b4f47d444.
These are presently "examples" (because they're just run
interactively, not automatable tests).
Conflicts:
tests/accessibility/Makefile.am
Being able to set a marker at a normalized point on a timeline, instead
of using a specific time, is a nice fit with the current Timeline class
API.
https://bugzilla.gnome.org/show_bug.cgi?id=694319
The behaviour imitates GtkEntry and ignores attributes from markup because Pango
barfs on invalid markup. Also add an example to the text-field interactive test.
https://bugzilla.gnome.org/show_bug.cgi?id=686477
When setting an explicit transform with clutter_actor_set_transform()
and a non (0,0) pivot-point, clutter_actor_apply_transform() will fail
to roll back the pivot-point translation done before multiplying the
transformation matrix due to the "out:" label being slightly misplaced
in clutter_actor_real_apply_transform().
This works properly:
clutter_actor_set_pivot_point (actor, 0.5, 0.5);
clutter_actor_set_rotation_angle (actor, CLUTTER_Z_AXIS, 30);
This results in the actor being moved to the pivot-point position:
clutter_actor_set_pivot_point (actor, 0.5, 0.5);
clutter_matrix_init_identity(&matrix);
cogl_matrix_rotate (&matrix, 30, 0, 0, 1.0);
clutter_actor_set_transform (actor, &matrix);
This also add a conformance test checking that even when using a
pivot-point, no matter how a rotation is set the resulting
transformation matrix will be the same.
https://bugzilla.gnome.org/show_bug.cgi?id=690214
The X11-specific windowing checks were hidden behind an #ifdef, however
if the tests were run under Wayland, they would execute uncondionally
and cause assertion failures. Fix this by also hiding them behind a
check that the current backend is indeed X11.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The current versions redraws all events on every redraw, which starts
getting very slow quickly. Instead simply draw only the new events
except when the cairo surface got reset, in that case redraw all events
again.
https://bugzilla.gnome.org/show_bug.cgi?id=681584
The CSS3 Transitions specification from the W3C defines the possibility
of using a parametrized step() timing function, with the following
prototype:
steps(n_steps, [ start | end ])
where @n_steps represents the number of steps used to divide an interval
between 0 and 1; the 'start' and 'end' tokens describe whether the value
change should happen at the start of the transition, or at the end.
For instance, the "steps(3, start)" timing function has the following
profile:
1 | x
| |
| x---|
| ' |
| x---' |
| ' |
0 |---' |
Whereas the "steps(3, end)" timing function has the following profile:
1 | x---|
| ' |
| x---' |
| ' |
x---' |
| |
0 | |
Since ClutterTimeline uses an enumeration for controlling the progress
mode, we need additional API to define the parameters of the steps()
progress; for this reason, we need a CLUTTER_STEPS enumeration value,
and a method for setting the number of steps and the value transition
policy.
The CSS3 Transitions spec helpfully also defines a step-start and a
step-end shorthands, which expand to step(1, start) and step(1, end)
respectively; we can provide a CLUTTER_STEP_START and CLUTTER_STEP_END
enumeration values for those.
It can be useful to check whether a ClutterActorIter is currently valid,
i.e. if the iterator has been initialized *and* if the actor to which it
refers to hasn't been updated.
We can also use the is_valid() method in the conformance test suite to
check that initialization has been successful, and that changing the
children list through the ClutterActorIter API leaves the iterator in a
valid state.
