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.
Now that we have a proper scene graph API, we should split out the
rendering part from the logical and event handling part.
ClutterPaintNode is a lightweight fundamental type that encodes only the
paint operations: pipeline state and geometry. At its most simple, is a
way to structure setting up the programmable pipeline using a
CoglPipeline, and submitting Cogl primitives. The important take away
from this API is that you are not allowed to call Cogl API like
cogl_set_source() or cogl_primitive_draw() directly.
The interesting approach to this is that, in the future, we should be
able to move to a purely retained mode: we will decide which actors need
to be painted, they will update their own branch of the render graph,
and we'll take the render graph and build all the rendering commands
from that.
For the 1.x API, we will have to maintain invariants and the existing
behaviour, but as soon as we can break API, the old paint signal will
just go away, and Actors will only be allowed to manipulate the 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.
It should be possible to ask a timeline what is its duration, taking
into account eventual repeats, and which repeat is the one currently
in progress.
These two functions allow writing animations that depend on the current
state of another timeline.
It should be possible to set up the delay of a transition, but since
we start the Transition instance before returning control to the caller,
we cannot use clutter_actor_get_transition() to do it without something
extra-awkward, like:
transition = clutter_actor_get_transition (actor, "width");
clutter_timeline_stop (transition);
clutter_timeline_set_delay (transition, 1000);
clutter_timeline_start (transition);
for each property involved. It's much easier to add a delay to the
easing state of an actor.
Clutter is meant to be, and I quote from the README, a toolkit:
for creating fast, compelling, portable, and dynamic graphical
user interfaces
and yet the default mode of operation for setting an actor's state on
the scene graph (position, size, opacity, rotation, scaling, depth,
etc.) is *not* dynamic. We assume a static UI, and then animate it.
This is the wrong way to design an API for a toolkit meant to be used to
create animated user interfaces. The default mode of operation should be
to implicitly animate every state transition, and only allow skipping
the animation if the user consciously decides to do so — i.e. the design
tenet of the API should be to make The Right Thing™ by default, and make
it really hard (or even impossible) to do The Wrong Thing™.
So we should identify "animatable" properties, i.e. those properties
that should be implicitly animated by ClutterActor, and use the
animation framework we provide to tween the transitions between the
current state and the desired state; the implicit animation should
happen when setting these properties using the public accessors, and not
through some added functionality. For instance, the following:
clutter_actor_set_position (actor, newX, newY);
should not make the actor jump to the (newX, newY) point; it should
tween the actor's position between the current point and the desired
point.
Since we have to maintain backward compatibility with existing
applications, we still need to mark the transitions explicitly, but we
can be smart about it, and treat transition states as a stack that can
be pushed and popped, e.g.:
clutter_actor_save_easing_state (actor);
clutter_actor_set_easing_duration (actor, 500);
clutter_actor_set_position (actor, newX, newY);
clutter_actor_set_opacity (actor, newOpacity);
clutter_actor_restore_easing_state (actor);
And we can even start stacking animations, e.g.:
clutter_actor_save_easing_state (actor);
clutter_actor_set_easing_duration (actor, 500);
clutter_actor_set_position (actor, newX, newY);
clutter_actor_save_easing_state (actor);
clutter_actor_set_easing_duration (actor, 500);
clutter_actor_set_easing_mode (actor, CLUTTER_LINEAR);
clutter_actor_set_opacity (actor, newOpacity);
clutter_actor_set_depth (actor, newDepth);
clutter_actor_restore_easing_state (actor);
clutter_actor_restore_easing_state (actor);
And so on, and so forth.
The implementation takes advantage of the newly added Transition API,
which uses only ClutterTimeline sub-classes and ClutterInterval, to cut
down the amount of signal emissions and memory management of object
instances; as well of using the ClutterAnimatable interface for custom
properties and interpolation of values.
As a convenience for the C API.
Language bindings should already be using the GValue variants.
This commit also moves the custom progress functions out of the
clutter-interval.c, as they are meant to be generic interpolation
functions and not ClutterInterval-specific.
The ::paint, ::queue-redraw, and ::queue-relayout signals should be
marked as no-recurse and no-hooks; these signals are emitted *a lot*
during each frame, and since GLib has a bunch of optimizations for
signals with no closures, we should try and squeeze every single CPU
cycle we can.
Dist clutter-version.h for use under non-autotools-based build
environments (e.g. MSVC) as this header is now generic under the
systems Clutter supports
Checked with Emmanuele Bassi on IRC.
The frame_budget member of ClutterMasterClock is only enabled when
CLUTTER_ENABLE_DEBUG is enabled, so fix the build with this.
Checked with Emmanuele Bassi on IRC.
Normally this leak goes unnoticed because basic fundamental types
are typically used with clutter_actor_animate(), the leak shows up
if boxed or object types are passed (such as ClutterVertex in the
case I stumbled upon).
The ClutterBrightnessContrastEffect effect class allows changing the
brightness and contrast levels of an actor.
Modified-by: Emmanuele Bassi <ebassi@linux.intel.com>
Modified-by: Neil Roberts <neil@linux.intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=656156
We can use the __COUNTER__ macro or, failing that, the __LINE__ macro to
ensure that we don't declare dummy variables more than once with the
same name.
The comment says that we're going to load textures in a loop until we
still have work to do, or if one iteration took more than 5
milliseconds, to avoid blowing up our frame budget, but the check is for
5 seconds, which is hardly a sensible value.
We remove 2 pixels from the height of the cursor, but we should also
remove the same amount from the position on the y axis, so that the
cursor caret appears centered in the allocated height.
https://bugzilla.gnome.org/show_bug.cgi?id=655491
ClutterScript should be able to automatically call gettext() and friends
on strings loaded from a UI definition, prior to passing the string to
the object it is constructing.
The basic implementation is trivial:
- set a translation domain on the ClutterScript instance
- mark the translatable strings inside the JSON data, like:
"property" : {
"translatable" : true,
"string" : "a translatable string"
}
The hard part is now getting the tools we use to extract the
translatable strings to understand the JSON format we use inside
ClutterScript.
Let's keep a budget of 16.6 milliseconds per frame, and reduce it by the
amount of time spent in each phase of the frame processing. If any phase
goes over the allocated budget then we use the diagnostic mode
facilities to warn the app developer.
It is sometimes useful to be able to have better control on when a
repaint function is called. Currently, all repaint functions are called
prior to the stages update phase of the frame processing.
We can introduce flags to represent the point in the frame update
process in which we wish Clutter called the repaint function.
As a bonus, we can also add a flag that causes adding a repaint function
to spin the master clock.
In theory, handlers connected to the ::allocation-changed signal may be
able to modify the actor's real allocation and allocation flags,
especially now that we use STATIC_SCOPE; let's avoid this, so that we
don't regret it later.
The show and hide implementation inside ClutterStage ended up being
recursive, and the hide implementation would actually show the children
of the stage unconditionally.
Whoopsie.
The ActorBox passed to the ::allocation-changed signal should be
annotated as STATIC_SCOPE, given that it's a pointer to a structure
inside ClutterActorPrivate - hence there's no risk of it actually being
freed from a signal handler. This allows the GSignal machinery to avoid
a costly copy/free for each signal emission.
