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.
At least for the time being, we only expose the parts of the API that we
want to use internally and for new, out-of-tree Content implementations.
The full PaintNode tree API will be made public in 1.12 once we branch
master.
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.
It's safer, and consistent with the rest of Clutter, to make sure that
the template pipeline we use for ClutterTextureNode has its wrap mode
set to clamp-to-edge.
Both ClutterCanvas and ClutterImage should use the minification and
magnification filters set on the actor, just like the use the content
box and the paint opacity.
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.
Instead of our homegrown string building; this at least ensures that
we're generating proper data, instead of random strings. Plus, using
JsonNode and JsonBuilder, we can ask the PaintNode subclasses to
serialize themselves in a sensible way.
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.
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.
If the redraw entry is not cleared, queueing a redraw from a signal
handler could reinsert the same object in the stage redraw list,
causing the segfault later (as the object is immediately freed)
https://bugzilla.gnome.org/show_bug.cgi?id=671173
This just adds some padding pointers so that we can later add more
virtual functions without breaking ABI.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
Clutter applications using evdev are typically fullscreen applications
associated with a single virtual termainal. When switching away from
the applications associated tty then Clutter should stop managing all
evdev devices and re-probe for devices when the application regains
focus by switching back to the tty. To facilitate this, this patch
adds clutter_evdev_release_devices() and clutter_evdev_reclaim_devices()
functions.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
When using the Wayland backend this sets a constraint that the
CoglRenderer selects the Wayland EGL winsys.
When a Wayland compositor display is set it now also sets a constraint
that the render should use EGL because only EGL renderers will set up
the required wl_drm global object.
The X11 backend now sets the X11 constraint.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
The core input devices when XInput doesn't work were being created as
generic ClutterInputDevices instead of ClutterInputDeviceX11s. This
meant the keycode_to_evdev virtual wouldn't work.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
This adds a virtual function to ClutterInputDevice to translate a
keycode from the hardware_keycode member of ClutterKeyEvent to an
evdev keycode. The function can fail so that input backends that don't
have a sensible way to translate to evdev keycodes can return FALSE.
There are implementations for evdev, wayland and X. The X
implementation assumes that the X server is using an evdev driver in
which case the hardware keycodes are the evdev codes plus 8.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
Because evdev isn't associated with the display system, it doesn't
have any easy way to associate an input device with a stage.
Previously Clutter would never set a stage for an input device and
leave it up to the application to set it. To make it easier for
applications which just have a single fullscreen stage (which is
probably the most common use case for evdev) the device manager now
associates all input devices with the first stage that is created
unless something has already set a stage.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
The shm buffer format enum values were renamed and the explicitly
premultiplied format was dropped since it's now assumed if the buffer
has an alpha component then it's premultiplied.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
The pick method doesn't do anything special over the default pick
method provided by ClutterActor so there's no need to implement it.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
This adds a signal that's emitted whenever a wayland surface is damaged
that allows sub-classes to override the default handler to change
how clipped redraws are queued if the sub-class doesn't simply draw
a rectangle. The signal can also be used just to track damage.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
This adds a "cogl-texture" gobject property so that a compositor may
listen for notifications of changes to the texture used to paint.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
This patch renames the width/height properties to
surface-width/surface-height so that they won't override the
width/height properties of ClutterActor which have different
semantics.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
This adds a NEEDS_XKB_UTILS automake conditional that's set to true if
either the wayland backend is enabled or the evdev input backend is
enabled since they both depend on clutter-xkb-utils.c and we need
to avoid listing the file twice since that leads to duplicate symbols
and the build fails.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
When a new buffer is attached and we update the width and height
properties for the surface we now also call clutter_actor_set_size()
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
This adds a clutter_wayland_surface_get_surface() function for querying
the struct wl_surface * associated with a ClutterWaylandSurface.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
This exposes a clutter_wayland_surface_set_surface() function. The
implementation ignores requests to re-set the same surface and since now
has code to cleanup old surface state before setting the new surface.
(previously the surface was construct only so this wasn't necessary)
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
When disposing a ClutterWaylandSurface we now make sure to unref any
pipeline we created and unref any surface buffer textures we created.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
There was a GArray member named damage that wasn't being used which this
patch removes.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
If wayland compositor support has been enabled then we make sure to
install the corresponding public headers and a
clutter-wayland-compositor.pc pkgconfig file.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
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.
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
It should be possible to adapt the abicheck.sh script so that it
actually tests the ABI of libclutter-1.0.so taking into account
the backends that were compiled into Clutter, and avoid expected
failures if Clutter was not built with a specific backend.
https://bugzilla.gnome.org/show_bug.cgi?id=670680
We cannot deprecate ClutterAlpha yet. We cannot also implement
ClutterAlpha in terms of ClutterTimeline, because multiple Alpha
instances can be attached to the same Timeline. So we can start
with a "soft" deprecation: just a warning in the documentation
stating that ClutterAlpha will be deprecated, and removed, in the
future, and that newly-written code should use ClutterTimeline
instead.
We can use ClutterTimeline and its progress mode inside
ClutterAnimation; obviously, we have to maintain the invariants because
of the ClutterAnimation:alpha property, but if all you set is the :mode
property using one of the Clutter animation modes then we can skip the
ClutterAlpha entirely.
Instead of having the easing functions be dependent of ClutterAlpha, and
static to the clutter-alpha.c source file, we should make them generic
and move them to their own internal header and source files. This will
allow to re-use them in the near future.
Since Cogl has started restricting what cogl 1.x api is exposed when
COGL_ENABLE_EXPERIMENTAL_2_0_API is defined and since we build all
Clutter internals with COGL_ENABLE_EXPERIMENTAL_2_0_API defined this
patch makes a first pass at reducing our internal use of the Cogl 1.x
api.
The most notable api that's no longer exposed to us internally is
the cogl_material_ api so this switches all Clutter internals to use the
cogl_pipeline_ api instead. This patch also makes quite a bit of
progress removing internal uses of CoglHandle although there is still
more to go.
The experimental cogl_texture_pixmap_x11_new() api was recently changed
to take an explicit context argument and return a GError on failures.
This updates Clutter's use of the api accordingly.
We were only exposing clutter_backend_get_cogl_context() if
COGL_ENABLE_EXPERIMENTAL_2_0_API had been defined but the CoglContext
api is also available if COGL_ENABLE_EXPERIMENTAL_API has been defined.
As it was it meant that code opting into the experimental Cogl api
but not limiting to the 2.0 only api would have to #define
COGL_ENABLE_EXPERIMENTAL_2_0_API before including clutter.h but make
sure it wasn't defined when including cogl.h which was particularly
awkward.
Recently the cogl_framebuffer_swap_* apis were moved into the
cogl_onscreen_* namespace since only CoglOnscreen framebuffers can be
double buffered. This renames all uses of the cogl_framebuffer_swap_*
apis in Clutter.
The experimental cogl_pipeline_new() api was recently changed so it
explicitly takes a CoglContext. This updates all calls to
cogl_pipeline_new() in clutter accordingly.
