It's been a year and change, and two stable releases, since we
introduced the paint volume mechanism to allow actors to paint outside
their allocation safely in environments that support clipped redraws.
The time has come to flip the switch, and return a valid paint volume,
matching the actor's allocation, by default - at least for Actor
instances from classes that do not override paint() and
get_paint_volume().
If an actor has a paint signal handler then it's the user responsability
not to paint outside the allocation - and to suffer the consequences of
doing so; in an ideal world, paint() would not be a signal in the first
place anyway. Plus, the idea that painting can happen at any time and
still have a valid surface greatly conflicts with the design goal of
making Clutter's rendering operations fully retained into a render tree.
We can still revert this commit before spinning 1.12, if need be.
When removing the last Action, Constraint, or Effect, we should also be
clearing the corresponding MetaGroup: code inside ClutterActor relies on
NULL checks, and changing them all to check for NULL && n_items == 0
would not be fun.
We need to remove the transition only if the current repeat is equal to
the number of repeats, and if the transition was marked as remove on
complete. Otherwise, the transition has to remain where it is.
The opacity internal setter will do it for us, and it will take into
consideration any eventual flatten effect applied to the actor.
This unbreaks the actor-offscreen-redirect conformance test.
We were using g_list_foreach() prior to the first Apocalypse, and that
function is resilient against changes to the list while iterating it;
since we are not using a GList any more, we need handle this case
ourselves.
When the easing state has a duration of zero milliseconds we can skip
the entire create_transition() call inside set_width() and set_height(),
to avoid what may be a costly call to get_preferred_*.
If we update a transition that is currently playing, we need to check
the current easing state, and look at the eventual duration, in case
the user wants to cancel the transition.
Instead of checking the duration of the current easing state we should
check if there's a transition in progress, and update it
unconditionally.
If there is no easing state, or the easing state has a duration of zero
milliseconds, then create_transition() should bail out early and set the
requested final state.
This allows us to write:
clutter_actor_save_easing_state (actor);
clutter_actor_set_x (actor, 200);
clutter_actor_restore_easing_state (actor);
[...]
clutter_actor_set_x (actor, 100);
and have the second set_x() update the easing in progress, instead of
being ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=672945
Commit 80626e7584 removed an
IN_DESTRUCTION check from within the add_child_internal() method,
outlining an option for bringing it back. It was too late for the 1.10
cycle to do it, and eventually pick up the pieces, but now that we're
at the beginning of the 1.11 cycle we can restore it, and add checks
elsewhere to balance it.
Should not have been there in the first place: the animatable will be
set either using ClutterTransition API, or when adding the transition
to a ClutterActor.
When adding a transition to a ClutterActor, the actor should hold a
reference on it, and release it only when we remove it. This makes
transitions just like other objects held by ClutterActor.
While you can get a per-transition notification of completion, it can be
convenient to also have a way to notify that all the transitions
involving an actor are complete. A simple signal triggered by the
removal of the last transition fits the bill pretty neatly.
If restore_easing_state() is called on the last easing state on the
stack, clean up the stack, so that we don't leave stale pointers
around to later segfault on.
When setting the easing mode, duration, or delay without having ever
called clutter_actor_save_easing_state(). It's confusing, and not
really nice.
In the future, we'll have a default easing state implicitly created by
the actor itself, but for the time being explicitly opting in is
preferrable.
Yes, it's not really the proper GL name for a linear-on-every-axis of a
texture plus linear-between-mipmap-levels minification filter, but it
has three redeeming qualities as a name:
- LINEAR_MIPMAP_LINEAR sucks, as it introduces GL concepts like
mipmaps in the API naming, while we're trying to avoid that;
- people using GL already know what 'trilinear' means in this context
without going all Khronos on their asses;
- we're using 2D textures anyway, so 'linear on two axes and linear
between mipmap levels' can be effectively approximated to
'trilinear'.
I mean, if even the OpenGL official wiki says:
Unfortunately, what most people think of as "trilinear" is not linear
filtering of a 3D texture, but what in OpenGL terms is GL_LINEAR mag
filter and GL_LINEAR_MIPMAP_LINEAR in the min filter in a 2D texture.
That is, it is bilinear filtering of each appropriate mipmap level,
and doing a third linear filter between the adjacent mipmap levels.
Hence the term "trilinear".
-- http://www.opengl.org/wiki/Texture
then the horse has already been flogged to death, and I don't intend to
be accused of necrophilia and sadism by flogging it some more.
Prior art: every single GL tutorial in the history of ever;
CoreAnimation's scaling filter enumerations.
If people want to start using 1D or 3D textures they they are probably
going to be using Cogl API directly, and that has the GL naming scheme
for minification and magnification filters anyway.
It's a bit late in the game for changing the emission of the paint
signal with actors that use paint nodes - mostly because we have both
implicit paint nodes (background color, content) and explicit paint
nodes (the paint_node virtual).
When we branch for 1.12 we can revert this change.
The ::paint signal is the old way to paint an actor; the paint_node()
virtual function is the new way. It's still not possible to traverse the
whole scene graph and build a render tree of PaintNode instances, but
with this change we simultaneously cut out the ::paint signal emission
from the critical path for actors that are using the new PaintNode-based
API, and we retain backward compatibility in the interim period between
1.10 and 2.0.
ClutterContent is an interface for creating delegate objects that handle
what an actor is going to paint.
Since they are a newly added type, they only hook into the new PaintNode
based API.
The position and size of the content is controlled in part by the
content's own preferred size, and by the ClutterContentGravity
enumeration.
The ::paint-node virtual inside ClutterActor is what we want people to
use when painting their actors.
Right now, it's a new code path, that gets called while painting; the
paint_node() implementation should only paint the actor itself, and not
its children — they will get their own paint_node() called when needed.
Internally, ClutterActor will automatically create a dummy PaintNode and
paint the background color; then control will be handed out to the
implementation on the class. This is required to maintain compatibility
with the old ::paint signal emission.
Once we are able to get rid of the paint (and pick) sequences, we'll
switch to a fully retained render tree.
As it turns out, we do end up recursing inside the ::paint signal
emission - especially inside the conformance test suite.
This thoroughly sucks - and we'll only be able to fix it properly
when we bump API for 2.0.
ClutterActor should be able to hold all transitions, even the ones that
have been explicitly created.
This will allow to add new transitions types in the future, like the
keyframe-based one, or the transition group.
